Irreal

Over at the Emacs subreddit, okimka suggests that an Emacs FAQ for the subreddit would be a good idea and even suggests a few questions and their answers. The comments generally complained about the questions and some of the answers but miss, I think, the main point.

Those on reddit and elsewhere spend a lot of time answering the same questions over and over. A lot of it is responding to the usual misinformed opinions of those who don’t even use Emacs. My favorite is “Emacs is unusable out of the box,” but there are also the complaints about it being bloated and slow. Rather than respond to those complaints over and over it makes sense to have some place we can point people to.

In addition to answering the usual complaints such an FAQ could address some of the other usual questions that we get repeatedly. I believe such an FAQ would be useful; what do you think?

Protesilaos Stavrou (Prot) just put up an interesting post that serves as a nice coda to yesterday’s Irreal post, Emacs As a 2D CLI. His take is not so much that Emacs fits nicely into the Unix paradigm but that for some things at least, it’s better. He builds his post around an email he got asking him why one should switch to Emacs.

His response is that if your current solution is working for you, there’s no reason to switch. Like me, Prot came to Emacs from Vim but for different reasons. We agree that Emacs and Vim offer two different types of workflow and reasonable people can prefer either over the other. He views Emacs as providing a unifying integration over the tools that he uses. Rather than writing glue code for every pipeline, he lets Emacs take care of that.

A couple of years ago, I wrote about a video in which Luke Smith asked people to send him videos (only) to convince him to switch to Emacs. I was not kind in my commentary because I found it annoying and presumptuous to ask the rest of the world to spend time providing very a specific type of content so he wouldn’t have to do his own research. His video was all the more annoying given that what he wanted was already available if he’d bothered to look. By happenstance, Prot’s interlocutor offers up another video by Smith in which he talks about the offerings he received and how he still wasn’t going to switch or even give Emacs and honest try. That video is as annoying as the first. His comments on Org-mode were particularly tiresome because they boiled down to, ‘Everyone says Org is cool; I don’t know anything about it; It’s not for me.’

Prot calls him out on the video saying he’s perfectly free to use whatever works best for him but that if he’s going to comment on Emacs he should at least know what he’s talking about. In other words, that he should give it an honest try for 6 months and then tell us what he thinks.

Prot’s post make a few other good points and also provides an alternative view of the Emacs/Unix question. It’s well worth a few minutes of your time.

Hongchao Liu has an interesting discussion about viewing Emacs as a two dimensional command line interface. He begins by arguing that Emacs does, in fact, adhere to the Unix principal of doing one thing well. That’s very counterintuitive but Liu says that if you view Emacs’ domain as text, then the one thing that it does well is to wrangle text. That’s not a new idea, of course; I wrote about it back in 2017 in connection with a post from ambrevar. Still, it’s a useful way of thinking about Emacs and its environment.

Liu’s other insight is that if you think about the normal Unix command line interface, it’s really about individual programs that have no knowledge of each other communicating through a text stream and they do this in a programming environment that we call the shell. That environment is inherently one dimension because the flow of data between the programs is basically a line of text.

With that in mind, Emacs can be viewed as a two dimensional command line interface. Rather than dealing with a line of text, Emacs deals with a two dimensional array of lines. In this case, the programming environment is Emacs rather than the shell. Liu uses the example of starting with a Magit commit log, jumping to a diff of the commit, and then to the actual source code of the program. As with the Unix pipeline, none of the programs know about each other and simply perform their work on the two dimensional array of lines that they are passed.

It’s an illuminating point of view and provides a neat answer to those who say Emacs is the anti-Unix. Take a look at Liu’s post. I think you’ll find it interesting.