
Evolution of Emacs Lisp [pdf] - signa11
http://www.iro.umontreal.ca/~monnier/hopl-4-emacs-lisp.pdf
======
nickdrozd
For those interested in the human aspects of Emacs development, be sure to
check out Appendix B, "INTERVIEW WITH JOSEPH ARCENEAUX". Many accounts have
been given of the FSF / Lucid Emacs "schism", but I think this is the first
time that his side of the story has been told. His perspective is unique in
that he was the only person AFAIK to have worked for both FSF and Lucid.

[1] shows the full email chain history surrounding the schism, along with
Jamie Zawinski's hilarious but partisan introduction. Arceneaux contributed
just one plaintive email:

> As the person somewhat in the middle this extended phlegm, it strikes me
> that both accounts of this history contain a certain degree of inaccuracy.

> Be that as it may, I would like to urge the parties involved to forget all
> this and again make efforts to join forces. Lucid has some talented hackers
> which can and have done good things for emacs (in fact, version 19 already
> uses some of their code), and if the "bosses" can work out their politics,
> the community will benefit.

[1] [https://www.jwz.org/doc/lemacs.html](https://www.jwz.org/doc/lemacs.html)

------
roenxi
Emacs is my text editor, I love it to bits but I don't have much interest in
whether it implements tail call recursion or if lambdas are implemented as a
macro. So while the article is a great bit of work, quite praiseworthy and
possibly an instant classic of Emacs lore I'm going to be critical of it
because I was hoping for something different.

Emacs the system is a programming environment that is used to create a model
of what a text editor should look like (in Elisp), then an implementation of
that model with windows and suchlike (in Elisp, C and with a bit more thrown
in for good measure). Extensions build on that model to accomplish magic of
various forms. I was anticipating an interesting read on competing ideas of
what that model should look like, and how extensions customarily interacted
with it, and how the culture has changed over time. 1985 was not the high
point for string manipulation and I expect there has been a lot of change
through the 90s and 00s, let alone the 10s.

This document is a record of the mechanisms behind the Emacs model. Important
to record, a great service for the archivists who really will care, but if I'm
going to invest an evening learning about mechanism I'd rather read up on the
JVM which is frankly more powerful and interesting than the Elisp interpretor.
Elisp is a historical curiosity to be sure and probably interesting diversion
to anyone implementing a lisp (who really should be looking to Common Lisps or
Clojures of the world for most of the inspiration), but it this document isn't
selling the interesting points of the story which is how it was being used. If
I'm reading about Emacs generators the only reason I can think of that they
are relevant to an Emacs user in in 2020 is in context of what the
implications of that are for how Emacs models documents and a text editor.

~~~
taeric
I'm skeptical that the jvm would have allowed anything we haven't had. Just
look at the crap show that was eclipse and the module system they came up
with.

I am actually somewhat convinced that s global namespace is one of the major
factors of growth for Emacs. Yes, namespaces can be nice. But there is
something about a playground that encourages all cards on the table.

And, notably, what makes elisp great is that that is largely the language that
Emacs is implemented in. Even if you moved elisp to be hosted on the jvm, I
shudder to think of having to do a ton of jvm inspired boilerplate to get a
quick extension in.

~~~
jolmg
> I am actually somewhat convinced that s global namespace is one of the major
> factors of growth for Emacs. Yes, namespaces can be nice. But there is
> something about a playground that encourages all cards on the table.

Isn't that a point of commonality with Lisp Machines? Not that I've used one,
but from what I read, one of their great aspects is that every function of
everything running in a Lisp OS was available for impromptu runtime
modification. IOW, you could modify anything even while it's running, without
the need to rebuild it and restart it like we do now.

Having a global namespace makes the hot-reloading easier by not having to
figure out in what namespace the redefinition should be happening.

That feature is pretty much only widely available in Emacs, now.

~~~
taeric
That is my understanding. But I don't know, if that makes sense.

It certainly sounds magical. And the few times I work with bugs in Emacs
libraries, it is amazing to jump to source so effectively.

