Hacker News new | past | comments | ask | show | jobs | submit login
Emacs Lisp book revived: Marcin Borkowski (mbork.pl)
91 points by nanna 7 months ago | hide | past | favorite | 27 comments

I've found the lack of resources to learning Elisp a challenge. I haven't finished it, but Robert J. Chassell's 'An introduction to programming in Emacs Lisp' seems to run through basic concepts but doesn't really get to the meat of actually putting everything together. (Could be wrong) And the Elisp manual reads like the output of an Elsip macro - so terse, so few examples, so much over my head. I've found Xah Lee's website helpful, but also completely overwhelming in all its detail. I'm after a guide. So I'm looking forward to this book by Marcin Borkowski.

Maybe others have suggestions of other ways to pick up Elisp?

Have you tried a combination of the Emacs Lisp Reference and looking through code?

There's one subtle but huge barrier to learning now: it used to be, you'd see Emacs add-ons posted as single text files, and it was all very accessible. And you'd copy that file into your home directory, and edit the Emacs Lisp of your `.emacs` file to connect it. You were already writing Emacs Lisp, and the files with more Emacs Lisp are right there.

Now, some well-meaning people made Emacs package managers (and there is some valid motivation for that) that take away this introduction of toes-dipped-in-the-water with quick transition to jumping in altogether, and then further hide the code from you. And if you ever do find the code, it's often directory trees with a dozen different "professional-looking" bureaucracy files in the top, and the source code buried somewhere else.

Which I assume gives people the impression that it's another "stack" to learn, where a lot of things are automated and have opaque layers of abstraction, and the bulk of the work is simply figuring out how to do something despite other people's piles and piles of bureaucracy. And then the next step is Web searches and cargo-culting from solutions of unclear validity from Stack Overflow.

Emacs is supposed to be an exceedingly accessible and incremental thing, where you're changing the code of your running editor, which you realize is a kind of super IDE, as you start to immediately learn its features for this kind of programming.

Consider ignoring your Emacs package managers, get the two main manuals up in Emacs Info mode, start using your `scratch` buffer to evaluate expressions like you find in the docs, see how to navigate between code and docs and keys, see how to turn on the debuggers, look through some code for some add-on packages, to see how they did those fairly well-scoped things. Somewhere in there, start making Emacs do some small thing that you want it to do -- and maybe make that your initial motivation and task, and everything I just mentioned was as-needed, in support of that activity.

It's a different approach from how we often have to work, in the current brogrammeresque world, and maybe a nice weekend/evening break from paid work. And -- though we might want to pretend otherwise, if we want it to be a change of pace from work -- the exercise of this different approach can mean skills and perspectives that we can bring back to the paid work.

> take away this introduction of toes-dipped-in-the-water with quick transition to jumping in altogether, and then further hide the code from you. And if you ever do find the code, it's often directory trees with a dozen different "professional-looking" bureaucracy files in the top, and the source code buried somewhere else.

Here's a bunch of tricks one should know if one wants to learn Elisp:

1. You can use describe-function (C-h f) or describe-variable (C-h v), as well as various apropos functions (starting with apropos, C-h a), you can find documentation about pretty much everything in Emacs, down to every single internal function or variable of any bit of Elisp code.

2. When you do that, you get a help buffer that almost always starts with something like "foo is a variable defined in `foo.el`". That "foo.el" bit is a link. You can click on it (or move your point to it and press Enter), and it'll land you straight at the definition of that function/variable. This is your shortcut to jumping straight into relevant source code of everything. Including C code, if you dig yourself into Emacs internals.

3. You can navigate to the help buffer in 2 from plenty of places, including e.g. the list of current modes, or description of a mode.

4. When you're playing around with Elisp code, xref-find-definitions (M-.) will take you straight to definition of a function under point.

Emacs is thoroughly documented and cross-referenced. Your own installation is its own single, living codebase - and you can navigate through it as such.

Thanks, that's what I meant by "see how to navigate between code and docs and keys", but was too lazy to type. :)

One important thing people should keep in mind, if they're starting only with Emacs navigation features for code and docs, is that they're missing crucial information that's in the manuals. One of the manuals is like a combination of the "API docs" you'll find in the docstrings, plus all the narrative around those, which you won't find in the docstrings. If a newbie is told only to browse docstrings and code, they're doing it on hard-mode.

And if a person makes sure they have the manuals installed (sadly, the Emacs Lisp manual(s) don't come installed by default in distros I've seen, which I think is a tragic mistake for uptake), and learns how load the manual in Emacs Info browser, and learns keys the Info keys like `i`, `s`, `[`, `]`, and `u`, I think they'll be glad they didn't try working from manuals in the Web browser.

Also, I wanted to start with making the code files more accessible and concrete, and generally tell people to try thinking differently about this. The reason is that I've suspected that a systemic barrier to accessible Emacs hacking was being created in the bureaucratic and obscuring direction things were going. (And it sounded like maybe this person was a victim of that suspected problem, since, when I started, it was much easier to get into, in the ways I described.)

(FWIW, I was able to write some Emacs extensions by starting with the approach I've suggested, including: https://www.neilvandyke.org/emacs/ )

This is good advice. I'm an elisp novice but I've found setting breakpoints using edebug (edebug-set-breakpoint) and then evaluating and traversing the code (edebug-eval-expression) to be very helpful in making the code more tangible (and obviously in debugging :)).

Good call! Will play around with this.

Sorry but emacs package managers don't get in your way anymore than the bundled libraries that come with emacs. They often have bugs/limitations you may have to hack around. But you can't modify them if they are globally installed with different permissions/read-only fs. In past i had to work around the tls client not having parameters for client certs by using advice hooks.

But you can easily jump around very deep into packages and compile them with few changes to suit your need. Your last resort is advice(https://www.gnu.org/software/emacs/manual/html_node/elisp/Ad...). Most of the time you don't need to and they have roughly the same benefits of your distro maintained packages vs you vendoring and compiling your own little world.

Dave Wilson is doing "The Lord's Work" when it comes to Emacs outreach, over on his System Crafters [1] YouTube channel. One of the series he is running there is an ongoing guide to Emacs Lisp.

[1] https://www.youtube.com/channel/UCAiiOTio8Yu69c3XnR7nQBQ

Thanks, yes that's true Dave Wilson's doing great work.

One other resource I actually found very helpful, pitched just right, is Musa Al-hassy's Elisp Cheatsheet. It's short but it gets straight to the detail. If he ever wrote a book I'd prepreorder it.


Thanks for both of these! I tend to just look up elisp stuff when it isn't clear from my Common Lisp knowledge, cheat sheets are perfect for this.

There's also Bob Glickstein's Writing GNU Emacs Extensions: Editor Customizations and Creations with Lisp (https://www.amazon.com/Writing-GNU-Emacs-Extensions-Customiz...), which I found quite good at the time. But it's really old. On the other hand, I don't know if it's out of date. :-)

Do you know any other lisps? I got by with the Elisp manual, but I already knew Common Lisp. Maybe a strategy is to find a great book teaching, say, scheme, and learn elisp after?

I'm pretty excited by Clojure so thinking of delving more into that, and then hoping it maps back onto Elisp, despite it lacking stuff like tail recursion. Would that make sense, or should I stick closer to the tree?

Maybe CL is the best route to Elisp... If so, any recommendations on how one might learn CL in 2021?

I actually only know CL and Elisp. I played a bit with Clojure, and its Emacs story looks pretty solid, but I was thinking it might be difficult to translate idiomatic clojure code to Elisp when Clojure has more emphasis on purity.

I'd guess that CL is closest to Elisp, especially when you use the popular "cl-mode", and you have the same mental model of hacking on a live lisp system. I learned CL from Paul Graham's "ANSI Common Lisp" back in the day, but I'd too be interested in what's recommended in 2021.

Yup. The closest is Common Lisp. Clojure’s idioms don’t match very well with Elisp oftentimes.

The best way to learn CL, IMO, is installing Portacle[1] and working through either Practical Common Lisp[2] or Common Lisp: a Gentle Introduction[3]. (I personally prefer PCL, but a lot of people like Gentle)

[1]: https://portacle.github.io/

[2]: http://www.gigamonkeys.com/book/

[3]: https://www.cs.cmu.edu/~dst/LispBook/index.html

Thanks, yes started reading through PCL last night, as it's online, and it's already cleared so much up for me. I'd never really thought about learning CL first until this thread, but now it feels like I've found the missing piece. And PCL is pitched exactly right, for me.

clojure uses immutabilty heavily. It doesn't really match 1-to-1 CL/elisp code. I think PCL(http://gigamonkeys.com/book/) is still a great introduction to CL. The author is planning a 2nd edition last i heard.

I'm curious if you have a good sheet on what differences are worth focusing on?

My main blocker is that it was originally tough to realize that the buffer is an essential part of elisp. Reflexively, I would look for ways to manipulate strings and be disappointed at how hard that was to find. As soon as I started seeing elisp as a way to program buffers, things got a lot easier.

Not sure if this is quite what you are looking for, but I found reading through GNU Emacs: Creeping Featurism Is a Strength (chapter 11 of Beautiful Architecture) at the suggestion of Eli Zaretskii to be extremely useful at painting the picture of the environment in which elisp code runs and the assumptions that it makes.

This is a cool idea too - will check it out. Many thanks!

I found doing the excercise on excercism.io very helpful. I read the manuals, some books, but actually writing code is the best. The nice thing about excercism.io is the examples have self checking code and you can get mentor feedback.


Good idea, thanks!

Interesting, I find that there are plenty of resources but they don’t actually cover my pain points.

There are plenty that teach elisp the language or that demonstrate consuming elisp packages, but it seems like not many in using elisp to modify the environment. By that I mean, okay I want to write a major/minor mode and have it update on.. keystroke? Any state change? And knowing which hooks/emacs internals to inspect/modify accordingly.

To be fair, I think Xah does a great job of this and most of this can be learned from reading source code. But sometimes I wish there were more direct answers out there.

Anyone know of a “cookbook” of sorts for common design patterns when implementing your own elisp packages that assume you know the basics of elisp?

I found the best way to understand Emacs Lisp (and Lisp in general) was to read the source code. The core Lisp interpreter is in 4 or 5 files that aren't huge. That was some years back so there might be more code now, of course. With that in hand, the actual Lisp code and built-in docs are good too.

I've looked at a lot of lisp books this week, and this didn't strike me as one I'd find useful, and particularly the sample chapter was uninteresting.

Looking forward to buying the completed book.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact