Emacs architecture info

I would love to read a book about the architecture of Emacs. Something that explain implementation details of elisp and the C core in it, with buffers, command system, and maybe the choices taken. A technical documentation. I know that there’s the source code, but some guide would be helpful. So any document, paper and similar that explain the Emacs architecture would be appreciated. TLDR: - Emacs chapter in the *Beautiful Architecture* book by O'Reilly - *The Extensible, Customizable Display Editor* [paper](https://www.gnu.org/software/emacs/emacs-paper.html) by R.M.Stallman - *Emacs for the Modern World* [book](https://web.mit.edu/~yandros/doc/craft-text-editing/) by Craig A. Finseth - *Evolution of Emacs Lisp* [book](https://dl.acm.org/doi/pdf/10.1145/3386324) by MONNIER and SPERBER

> Something that explain implementation details of elisp and the C core in it, with buffers, command system, and maybe the choices taken. A technical documentation. There is [a bit in the manual](https://www.gnu.org/software/emacs/manual/html_node/elisp/GNU-Emacs-Internals.html), but probably not as extensive as you are asking for. Look in the sources, there are some quite extensive comments, which will give you more insight. Another good source would be [emacs-devs archives](https://lists.gnu.org/archive/html/emacs-devel/). Often, if you search on some topic, they will pop up in the web search. If you are interested in Emac's Lisp dialect, there is a bit about it in [this paper](https://dl.acm.org/doi/abs/10.1145/3386324). > I would love to read a book about the architecture of Emacs. Me too. We can just hope that Mr. /u/eli-zaretskii will get tired of managing Emacs releases and write a great book about Emacs internals, architecture decisions etc ...

RemindMe!

**Defaulted to one day.** I will be messaging you on [**2022-05-21 07:49:20 UTC**](http://www.wolframalpha.com/input/?i=2022-05-21%2007:49:20%20UTC%20To%20Local%20Time) to remind you of [**this link**](https://www.reddit.com/r/emacs/comments/utmmbe/emacs_architecture_info/i9awfe2/?context=3) [**CLICK THIS LINK**](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5Bhttps%3A%2F%2Fwww.reddit.com%2Fr%2Femacs%2Fcomments%2Futmmbe%2Femacs_architecture_info%2Fi9awfe2%2F%5D%0A%0ARemindMe%21%202022-05-21%2007%3A49%3A20%20UTC) to send a PM to also be reminded and to reduce spam. ^(Parent commenter can ) [^(delete this message to hide from others.)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Delete%20Comment&message=Delete%21%20utmmbe) ***** |[^(Info)](https://www.reddit.com/r/RemindMeBot/comments/e1bko7/remindmebot_info_v21/)|[^(Custom)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5BLink%20or%20message%20inside%20square%20brackets%5D%0A%0ARemindMe%21%20Time%20period%20here)|[^(Your Reminders)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=List%20Of%20Reminders&message=MyReminders%21)|[^(Feedback)](https://www.reddit.com/message/compose/?to=Watchful1&subject=RemindMeBot%20Feedback)| |-|-|-|-|

> We can just hope that Mr. /u/eli-zaretskii will get tired of managing Emacs releases and write a great book about Emacs internals, architecture decisions etc ... I remember him repeatedly saying on emacs-devel that if something about the display engine is unclear to people, they should ask their specific question and he'd try to answer it.

Indeed. I have seen him repeatedly answer in general, pretty much every technical question about Emacs internals, at least in last few years, or if not every, very many of them. So it is a very good tip to post a question on emacs-devel mail list. Thanks for pointing it out.

And whatcha do when he ded? I mean, clearly you'd just have to read through the source code and all that, but it's not like you can ask any questions at that point.

I find looking through the sources to be the best way. For example, since I am often accessing Emacs through a console port (slow) I was always fascinated with how on things like a long build with similar compilation commands the window in the buffer would optimize output to only update the file name being compiled, leaving untouched the part of the window showing the compilation parameters. Emacs has been optimized like this “forever”. Only the code really explains how that works.

Check out the Emacs chapter in the Beautiful Architecture book by O'Reilly.

This is a two-step optimization process: first, Emacs produces the "desired" contents of the smallest portion of the screen that it thinks needs to be updated, and then it actually compares the current and the desired screen contents to find the minimum area that needs to be updated. And that is what finally gets written to the glass.

I thought https://dl.acm.org/doi/pdf/10.1145/3386324 [pdf] was a good read, but it may not be exactly what you're looking for.

I haven't read it myself, but 'The Craft of Text Editing' might be what you're looking for. It's alternative title is 'Emacs for the Modern World' [https://web.mit.edu/~yandros/doc/craft-text-editing/](https://web.mit.edu/~yandros/doc/craft-text-editing/) It will be a bit out of date on some details, but the resources other people have posted here could get you up to date.

Reading it now and it's a good starting point! thanks

Wow, it's really interesting. Has implementation details and discussion. Added to the reading list. Thanks!

Is about text editing and describe an approach to take while writing one... is a great document! Reading this one too, thanks!

I also found *Emacs: The Extensible, Customizable Display Editor* that is the paper written by Stallman in 1981, in case someone else is looking for similar documentation. https://www.gnu.org/software/emacs/emacs-paper.html

There are a few other formats of that same work available directly from the author these days: https://www.finseth.com/craft/

You ask before that happens, so get going.

Doesn't invalidate the point. He could kick the bucket by accident. Documenting things beforehand as a preventative issue would solve that.

I'm certain you've heard about the phrase "The perfect is the enemy of the good" and can figure out how it applies to the situation here. Certainly, I'm calling neither option perfect or good, but I'd prefer having one solution than none at all.

I've certainly heard of it, but with the intent of it in mind, it doesn't really apply here. It is not one or the other, nor is it expected that a perfected form of documentation covering every conceivable situation will be cooked up. Some is better than none, so long as some care is taken when making it, because two is better than one.