Hey there.

I’m a fan of Emacs, like you folks.

I use Emacs org every day, mainly for my teaching class. Furthermore, I learn Emacs for three years ago.

But I struggle to achieve my learning of Elisp. For example, taping lisp and elisp code with evil/lispy is a true nightmare (I use Prelude with few modes, btw), not to mention when I type code block within org.

I knew the learning curve is hard. But I didn’t expect that much frustration to learn it. The documentation is austere. So few examples are given. There is too little blogs or books about Emacs, specifically about org and babel.

To illustrate my point, let’s take the «*this*» kind-of macro in babel, that I found TODAY by CHANCE in this page : https://orgmode.org/manual/Results-of-Evaluation.html.

It’s a game changer for a lot of my code, and would deserve a whole page to illustrate it. But no, it’s given in a «niche» example.

Don’t be mistaken, I found Babel/Org/Emacs wonderful, but what a pain in the ass to learn it !

For such an old and wise piece of software, I can’t understand why we don’t have a smooth learning experience with Emacs. A lot of people could benefit Org/Emacs, without the big hinder of the «lack» of documentation (mostly examples).

Am I the only one to experience this ?

  • abbreviatedman@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    What makes learning Emacs and Elisp so hard? I think you’ve begged the question in the classic sense—your question contains the answer! The issue I think is that to really understand Emacs you have to understand Elisp and the Emacs environment.

    If you focus only on one, it’s hard to work with Emacs. Knowing Elisp without understanding how to work with hooks, and modes, and when (and whether) to work with the Custom system, and when configuration code should load before vs. after a package loads… well, you’re not going to be able to do a whole lot with that Elisp! And Emacs knowledge without Elisp means you’re going to know what you want to do and maybe even how to do it but you’re going to have some fundamental misunderstandings of the code itself, leading to errors and bugs and a lot of frustration.

    Thinking about this, I think the reason the documentation can be so challenging to figure out is that, as someone said further up there, this is all run by volunteer efforts, and, as such, they have to prioritize where their limited resources go. So the approach it seems to me that they’ve taken is to document as much of the Emacs environment as they can, but focus not on all of Elisp, but how it’s different from other Lisps, and assume you can teach yourself Lisp.

    I’m not really sure it’s true that this was the purposeful prioritization from the documentation writers—there’s a pretty extensive Elisp manual, and a nice Elisp tutorial in the manual (typically C-h i)—but it’s not the level of resources nor the beginner-friendly approach that you see with learning a (somewhat) more practical Lisp, like Scheme or Racket or Common Lisp or Clojure. I don’t mean to put words in the mouth of the tireless and selfless documentation writers, nor at all demean them! But either way, it’s the same result from a learner’s perspective.

    So given the situation (as I see it), how do you learn Emacs? I highly recommend learning another Lisp, since there are more resources and tutorials on those than Elisp. Racket and Scheme.are IMO the easiest to get started with, and fun besides.

    One final thought on learning Emacs: I think I stunted my growth for a while by using a framework on top of Emacs—I learned neither proper Elisp nor how Emacs worked. I learned a little about how my framework worked, and little about Emacs itself. I used Doom Emacs, but most frameworks have this issue. I’ve heard there are some frameworks that are better geared towards teaching you Emacs, so maybe this doesn’t apply at all. But I think Doom Emacs is more geared to transitioning folks from Vim (which helped me, for sure!), and the framework they’ve built on top of it, while powerful, isn’t, in my “n of 1” experience, good for learning.

    Anyway, hope these thoughts help, and besides agreeing with folks that one of the best things you can do to learn and help others learn is to contribute to the documentation, this and the org-mode reddit are good places to ask clarifications—especially if it’s clear it’s a clarification and you’ve attempted your research first! (We’re friendly, but we’re friendlier if you demonstrate you’re putting in the effort too.)

    Cheers!

    • SuLinab@alien.topOPB
      link
      fedilink
      English
      arrow-up
      1
      ·
      11 months ago

      Thanks a lot for your response.

      I will consider leaving prelude away, and dive into my own Emacs configuration. I am afraid of the time-consuming experience that it will be, but I hope it’s worth it (and seeing the responses here, I definitely think it is).

      • timmymayes@alien.topB
        link
        fedilink
        English
        arrow-up
        1
        ·
        11 months ago

        Learning emacs via the emacs for scratch setup drive me into learning elisp. I’m no guru but it did set me up with a really solid foundation.

      • geza42@alien.topB
        link
        fedilink
        English
        arrow-up
        1
        ·
        11 months ago

        I think one has to be pragmatic, and only put effort to features that are actually useful. Don’t put hours writing an elisp function which only saves you 10 seconds in a month. I’m saying this, because I had to stop myself from spending time on Emacs. I realized that my config is OK for me. I still have a lot of ideas how to make it better, but I simply don’t do them, because it doesn’t matter too much. Of course, I still do smaller tweaks, but otherwise I spend my time on more useful things. If someone had told me this before I started using emacs, they would have saved several days of not-too-useful emacs configuration for me. Of course, it was fun, I did it as a hobby, but still, it wasn’t the smartest way to spend my free time.