Irreal

Christoffer Stjernlöf over at Two Wrongs has a very well done post on Why You Should Buy Into the Emacs Platform. Posts on “Why I moved to Emacs” are common, of course, but Stjernlöf has written a comprehensive post that recognizes Emacs as more of an environment than just an editor.

He notes, for example, that you can edit code with any old editor but only Emacs can give you Magit. He says that Magit alone is reason enough to adopt Emacs but there are many other applications available with the Emacs platform. You can even write your own applications for Emacs if you like.

There’s no point in me listing all the Emacs features and packages that Stjernlöf admires; you should go read his post. Nonetheless, it’s worth noting that in keeping with his holistic view of Emacs, Stjernlöf lists many ELPA packages that he finds useful. Evaluating a piece of software by taking into consideration addons that third parties wrote my seem like cheating but it isn’t. Almost all of us have several packages installed to make our editing easier or to deal with tasks such as Email or RSS. It’s the packages that make Emacs an environment worth spending the time to explore and learn.

In any event, Stjernlöf’s post is interesting and worth a read.

Mike Zamansky has posted another video in his Using Emacs Series. This time it’s about configuring Irony to get completions for C++. Personally, I don’t use things like company-mode and irony-mode because I don’t like having random buffers pop up offering to complete whatever I’m writing. That’s a minority position, I know, so if you do like the idea of completions and you write in C++, you should definitely take a look at Zamansky’s video on how to get things working.

The video is only 3 minutes, 48 seconds so you should be able to sneak it in no matter how busy your day. As always with the Using Emacs videos, it’s well worth your time even if you aren’t particularly interested in completions.

It appears that I’m temporarily at the end of the Internet: I can’t find anything interesting to write about today. Instead, here’s a rant.

I’ve written before that the Lisp Community’s well-known crabbiness with n00bs is probably the result of having the first thing said n00bs do when joining the community is to suggest some scheme or other for doing away with parentheses. If you’re a Lisper, you know how quickly that gets old. If you’re not a Lisper, you can take my word for it.

Sadly, I recently noticed a parallel offense on the part of Emacs n00bs. Many of them come to Emacs, notice that the extension language is Lisp, and suggest that we rewrite Emacs in a “modern” language such as JavaScript, Python, or Ruby. Here’s a recent example that inspired this rant. As you can see, the poster has no idea of the architecture of Emacs or why things are the way they are. That’s alright: he’s a n00b and no one expects him to understand that stuff out of the box. That said, it’s a good idea understand a subject before you start agitating for wholesale changes.

Here’s a bit of truth for all the n00bs out there: Parentheses, Elisp, and plenty of other things you don’t like or understand aren’t going anywhere. You can make whatever suggestions you like but if you want to be received cordially and have your suggestions treated with respect, take some time to understand the community and whatever it is the community was formed to support.

Postscript: I’ve mentioned this before but it bears repeating. Notice how gentle and respectful those responding to the poster were. The Emacs community really is a friendly and welcoming group of people.

Back in 1979, Bernard Greenberg wrote a long document about Emacs on Multics. If you’re interested in the history of Emacs and how it evolved, you’ll probably enjoy reading through the document. It’s fairly long and detailed but all that detail is revealing.

It’s hard today to appreciate how difficult it was to implement Emacs—or any video editor—on a large mainframe like the H6000 system that Multics ran on. The problem was that the hardware didn’t really support per-character input and processing—let alone echoing the characters to the display—so special effort, including patching the OS, was necessary to make it work.

Multics was written in Multics PL/I, which despite being a complete, well designed language was not suited to incremental development. It was, therefore, a poor choice to implement Emacs with its extensibility. Instead, the controversial decision to use Lisp was made—remember that the original ITS Emacs was built as a set of macros on top of the TECO editor. That fateful decision with its profound effect on Emacs extensibility is still with us today. It’s success should give pause to those suggesting alternative languages such as Python, JavaScript, Ruby, or whatever as the Emacs’ implementation/extension language.

By reading Greenberg’s account, you see why Emacs is the way it is today. Although the text representation was different from today’s gap buffer, many of the original implementation details can still be seen in the current versions of GNU Emacs.

As I said, it’s a long document but worth reading if you’re interested in Emacs’ history and beginnings.

UPDATE [2019-01-19 Sat 15:10]: Goldberg –> Greenberg