Irreal

I’ve long since moved all my writing—at least all my new writing—to Org mode. It does everything I need and let’s me stay in Emacs. Different folks favor different strokes, of course, so it’s always interesting to see what they are and especially how they use Emacs to scratch their itches.

Azer Koçulu recently moved to Linux from macOS and wanted to bring his writing protocol with him. He was using iA Writer on his Mac but it wasn’t available on Linux. Koçulu decided to see if he could recreate the iA Writer experience in Emacs. He was happy with the result and documented what he did in a blog post. It turns out that it’s pretty easy to set up an iA Writer environment in Emacs. I’m not an iA Writer user so I can’t say how well it recreates the experience but Koçulu is happy with it.

There’s probably a larger lesson here. If you really like some writing tool but need to move to an environment that doesn’t support it or want to move to Emacs for your writing for some other reason, Emacs probably has you covered. Koçulu shows you how to do it for iA Writer and here’s a video showing how to do it for Scrivener. Doubtless solutions exist for other tools too.

I saw this tweet:

I am experimenting with using #Emacs as my main programming environment. The last time I used emacs extensively was in college. Yes it is a bit old school but if you have to edit many files scattered in many directories, emacs is unbeatable.

— Hsin-Hao Yu (@HsinHaoYu) October 6, 2018

and my first reaction was that it made me feel old. But then I started wondering: in what sense, exactly, is Emacs “old school?”

Certainly not in the sense that it’s a relic. Emacs development is on-going and vigorous. And not in the sense that it’s underpowered and lacking features, either. Emacs is famously the “kitchen sink” editor, containing every possible feature. At one point, a kitchen sink was even used—at least informally—as its logo.

Perhaps it’s old school in the sense that it’s mostly used by gray beards. But no, younger users are constantly adopting Emacs as you can see by their questions and comments on the various forums. Maybe it’s that Emacs is not up to some modern tasks. Again no. Emacs is so extensible that you can configure it to do any possible editing task. You can even understand it as an editor construction kit. As I wrote the other day, no editor can claim to be more powerful because whatever feature they base that claim on can be added to Emacs, probably relatively easily.

So what’s the answer? Bling. Emacs doesn’t have any. I suppose if you really wanted it, you could add some chrome to Emacs but it’s beside the point and most Emacs users don’t see the need for it. To reuse my previous analogy, you don’t want a sports car for working the farm.

So I’ll embrace the “old school” label and wear it proudly as I use the most powerful editor possible even if it is a plain Jane.

As you all know, I really like the idea of email within Emacs and collect various solutions to implementing it. I’ve long settled on mu and mu4e and have no intentions of looking for something else. Still, it’s nice to see what software and configurations other people pick.

Aqeel Akber has settled on his own perfect email setup. His uses notmuch for both the indexer and mail client. Like me, he uses to mbsync to retrieve his email (from Google in his case). Unlike me, he uses msmtp to take care of sending his emails. This is an advantage because, among other things, it takes care of queuing his emails if they can’t be sent immediately.

Akber likes to partition his computer system into “subsystems,” which he believes makes them easier to configure, manage and reason about. His configuration reflects this but you needn’t blindly follow his setup. On the other hand, if you want to, you can simply download his configuration and make the necessary changes to have a similar system. If you’re looking for an Emacs/Email solution, Akber’s post is worth taking a look at. A problem that many seem to have is how to get mbsync to work with Gmail. Akber has solved that problem so if you have it too, that alone makes his post worthwhile.

I have always felt that knowing, at least in a general way, how a higher level language compiles down to machine code enables one to write better code in the higher level language. That’s not to say that everyone should learn their processor’s assembler language—that’s not necessary these days and would require an effort greater than the expected returns—only that you should be able to read an assembly listing and get a general idea of what it’s doing. This seems so obvious to me that I don’t understand how people can disagree. Some do, however, and they probably won’t be interested in this post.

For many languages it’s possible to get a listing of the assembler output or, in the case of languages like Python, a listing of the bytecode. The problem is that in most cases it’s enough trouble that you won’t bother unless you have a pressing need. Jay Kamat’s RMSbolt package makes everything easy and will give you an automatically updating display of the generated code in a window next to your source code.

Take a look at the animated GIFs in the project’s README to see it in action. This is really ideal because it will let you try alternative statements and see how their code differs. Compilers are always doing surprising things, sometimes even erroneous things, so this can be very useful.

RMSbolt supports C/C++, OCaml, Haskell, Python, Java, Pony, and (limited) Common Lisp. It’s available from Melpa and doesn’t require anything other than Emacs 25 or greater and whatever compilers you’re using.

UPDATE [2018-10-03 Wed 17:55]: Fix link.