Irreal

When it comes to eliminating workflow friction, few do it better than Matus Goljer (Fuco1). His latest post describes a fix for a problem that I didn’t even know existed: When Org pops up a log note buffer (after a change of task status, for example), the input method reverts to English. That’s fine if English is your native language and you’re shamelessly provincial like me. As I say, I didn’t even know it’s a problem. But English is not Goljer’s first language and he, of course, prefers to use an input method appropriate for his native tongue. The problem is, the log note buffer reverts the input to English.

As Goljer notes, that’s ironic given that the current maintainers are also not native English speakers. In any event, he put together a few lines of Elisp that solved the problem for him. As he says, he spent a total of about 2 minutes on it, far shorter than the time he spent searching for a solution in the manual.

If you also use a default input language other than English, be sure to take a look at Goljer’s post for an easy fix. If you are a native speaker, you might also want to check out his post just to see his code. I learned a couple of new Elisp functions that I didn’t know about so it was worth it for me.

Continuing yesterday’s theme of moving to Emacs, let’s discuss some ways of easing the transition. Nikhil Soni has a nice post that describes how he got Emacs to provide the features he was used to from editors like VSCode, Atom, and Sublime.

In particular, he wanted Emacs to give him these functionalities:

1. Duplicate current line
2. Move a line up or down
3. Multiple cursors
4. Auto-completion
5. Fuzzy search for file name
6. Project tree view
7. Go to function or class definitions
8. Return to previous cursor position
9. Find all function references
10. Markdown preview

Most serious Emacs users already have solutions for these but Soni goes through them one-by-one and shows how he implemented them. Almost every item was implemented by loading a package or with a (very) few lines of Elisp. Soni shows the Elisp in his post but also provides a pointer to the file in his configuration that provides them.

It’s a nice post that demonstrates that there’s nothing—other than bling—keeping you from upgrading from VSCode, Atom, or Sublime. Or so I say. Some partisans of those other editors will doubtlessly strongly disagree. That’s alright. As I’ve said before, the choice of an editor is a personal, not a moral choice. Of course, if you want the best editor…

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