• 0 Posts
  • 10 Comments
Joined 11 months ago
cake
Cake day: October 19th, 2023

help-circle

  • erez@alien.topBtoEmacs@communick.newsI love emacs
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    Keep in mind that I did not mention either of those by name, you did, so you’re debating yourself rather than me. I’m just saying that making a tool, any tool, work best for your use case doesn’t mean you can’t achieve the same result with another tool, or set of tools after similar customization etc.


  • erez@alien.topBtoEmacs@communick.newsI love emacs
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    Once you learn how to navigate, customize, workaround and enhance a system in a way that fits your need, yes, good luck using another tool that you now need to learn how to navigate, customize, workaround and enhance to use in a way that fits your needs, ha!




  • erez@alien.topBtoEmacs@communick.newsi wanna try emacs
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    Emacs is the opposite of the Unix way, as are many of the GNU tools. It’s the opposite of “each tool does one thing and does it well” and is a “one thing will do everything, sometimes well and sometimes less”. And since you already have a solution you are using, and are committed to the cargo cult of VI keybindings, then there’s no reason for you to try emacs.


  • I’m aiming at both sides. I have used a library in work that had a utf8 issue, and started digging through the issues on GitHub, only to find that each such issue was flagged as “wont fix” and the reason was 'no activity on this issue for X amount of time". Which is a tactic I would get fired for had I tried it. I pointed this out and immediately got “we-hell, Pull Requests are welcome”. Which is rather not helping. Also, turns out it’s a matter with a dependency of that library, which you only found if you went through each issue. But then again, that guy was publishing that library out of the goodness of his heart, so you can only bitch up to a certain point. It’s kinda odd because that bug caused me to waste a day and that meant I wasted my employer’s money on the issue. So this “labour of love” and voluntary effort can cost people money due to the “I’m not getting paid to do this” attitude sometimes involved with the project. IT is a double edged sword.


  • If I understand correctly, you are asking why is documentation using bad code examples that are not explanatory and/or usable?

    If so, then I believe we can exonerate the emacs community from this issue as this is an industry-wide problem. I recall trying to figure out what a .NET class do from the generic unusable examples given in MS code, and more recently trying to divine meaning from the almost usable but never truly so code examples in Angular documentation. And you’ll see that everywhere. I got used to ignore documentation and just read the code. Tests sometimes help as they are actual programs that use the stuff in question, but it does seem like writing good, usable documentation is an art form no one bothered to master. Or even apprentice in.

    There’s a reason to that, code examples are written by people who are experts in the technology they are documenting. They have no way of knowing what is needed for someone new to understand in order to use it, so they default on writing the most basic code example they can come up with. It’s a known issue and you eventually learn to live with it.

    Also, don’t bother complaining. You are getting this great tool (either emacs or Org-Mode) free and due to the great effort of its writers and maintainers (and I am always amazed at the scope of things that were created this way, it’s truly something to be proud of), so be thankful that it actually has documentation and besides, if you don’t like something, fix it and send them the patch, don’t complain! I mean, you won’t get to write that patch because you can’t understand the program due to its documentation, but hey, who said life is fair.