high12noon blog

Adventures with Emacs

Back to main page

This page is a work in progress. I am documenting my adventures with GNU Emacs as I learn the editor / operating system. Page created April 20, 2022; last updated December 5th, 2024.

Table of Contents

Why Emacs?

April 20, 2022

A good text editor is a must-have for anyone who does more than a superficial amount of text editing, as in programming and other computer work.

What constitutes a "good" text editor may be quite subjective, but could be summed up as follows: It should provide a natural and efficient method of editing so that the computer can become an extension of the mind and the task of editing text doesn't interfere with the mind's train of thoughts. This is equally important whether editing program code or writing a novel.

For about two decades, I used a commercial (read: PAID) text editor as my daily driver. This editor was and still is maintained by a family-owned business. When I adopted it in the early 2000s, it was sold as "shareware" which meant it could be tried for free for a limited time and then unlocked for perpetual use by purchasing a license. I liked the editor, I liked the company, I liked that the programmer who created it was available to answer questions and fix bugs quickly, and I bought the paid license (more than one, in fact) and recommended this editor to numerous people and businesses over the years. To be clear, I still like the editor and the company.

So what happened?

Several factors came into play and made it clear to me that I would need to switch text editors.

One factor is the operating system. The unnamed editor is a Windows application. This made sense at the time of adoption, when I was using Windows 98, followed by Windows 2000, followed by Windows XP. But over the course of the next few years, the evolution of my work meant that I would start using Linux, FreeBSD, and Mac OS X. Suddenly I needed to edit text on these other operating systems. I was still a heavy Windows XP user, though it changed from being the native OS running on the computer to being virtualized in a succession of system-in-a-window emulation and virtualization products, free and paid. Besides the editor, I routinely used quite a few Windows-based programs that were irreplaceable (or at least not easily replaced). Since I always had an instance of Windows running in a window, it wasn't a terribly big deal if my favorite editor was running inside that. But as time went by, gradually it became less and less necessary to use those irreplaceable programs, each for its own reasons, and they began to drop out of my life one by one. At some point, the editor remained as the only significant program I still used with any regularity.

I might have continued running a Windows XP instance inside a virtual machine just to keep using my favorite editor, but this comes with several significant problems. First, Windows XP is no longer supported and hasn't been for a while. This means no more security fixes. I might have upgraded to a later Windows, but each version from Vista and up requires significantly more resources than Windows XP and that just doesn't make sense when the only program I'd run would be the text editor. Second, speaking of resources, even a Windows XP virtual machine, which is light and fast on today's powerful computers, occupies much more RAM than any reasonable text editor would when running natively within the OS.

Both of these issues (lack of security maintenance and excessive resource use) could be easily mitigated by removing the network connection from the virtual machine and installing more physical RAM in the computer. But there's a third and bigger issue looming: It seems to me that the market wants to move away from the Intel instruction set and toward ARM and perhaps RISC-V. Almost all smartphones and tablets use ARM CPUs now. Apple's new silicon uses the ARM architecture. Countless embedded systems-on-a-chip (SoCs) are based on ARM cores of various types and capabilities. Adding all of these together, I think it's safe to assume that there are already far more ARM-based computers in the world than Intel-based ones.

Virtualization, which is how I was running Windows XP, actually runs the virtualized software on the computer's native CPU. This is one significant way that virtualization differs from emulation. The other is that emulation is noticeably slower than virtualization, since each CPU instruction of the emulated software must necessarily be implemented by software, which ultimately translates to numerous native CPU instructions by the time it's parsed and processed. If I wanted to insist on running my favorite text editor on Windows XP within an emulator, which is what I'd need to do if on an ARM-based computer, the resource use and efficiency would be far worse than under my current virtualization setup.

Time will tell whether Intel will ultimately take back the market, and hopefully my current computer, which is an Intel architecture, will last for a long time to come, but if and when the time comes to replace it, if the prevailing architecture is ARM, that would put the final nail in the coffin of running Windows XP, and by extension, my favorite editor.

Now wait a minute, one might say. Aren't there versions of Windows that run on ARM? Yes. Does my favorite editor support that? I don't know. What about WINE, an emulation layer that makes it possible to run Windows applications on Linux? I haven't tried that.

But there's something I haven't mentioned yet, and that's the editor's user interface. Some years ago, the company that makes the editor decided that the software needed a refreshed look and feel, so they rearchitected the user interface, eliminated the menu bar and toolbar that all circa-1998 Windows applications had, and replaced those with what's called the "literate" user interface style in the Windows world. This is a sort of context-sensitive combined menu and tabbed toolbar, with some toolbar buttons larger than others. You've seen this interface style if you've used the built-in file manager on any Windows 10 computer. Unfortunately, this rearchitected GUI, though attractive in my opinion and sensible in theory, came with a big side effect which was quite undesirable to me: It completely trashed almost two decades of deeply ingrained muscle memory.

To explain this, I have to mention how the Alt key on the keyboard works under Windows. It can be held down and another key pressed at the same time; for example, Alt-X is a common shortcut key to exit a Windows application. That is, the user presses and holds down the Alt key, presses and releases the X key, and then releases the Alt key.

But Alt can be used another way as well: The user can "type" the Alt key, meaning press and release it like any other key. When this is done, focus goes to the application's menu bar and one letter of each menu item becomes underlined to indicate that it can be typed to activate that menu item without navigating to it with the mouse or arrow keys. This is incredibly convenient, and sadly I have not seen a similar feature under Mac OS X or any Linux/Unix GUI.

When I first adopted this text editor, I learned to quickly reach many oft-performed operations by typing Alt, typing the appropriate letter to open the desired pull-down menu, and then typing the appropriate letter to activate the desired item within that menu. This method of typing a sequence of three keys was very convenient for me, since it was very fast and also came with immediate visual feedback, since it opens the menus.

When the text editor was rearchitected with the "literate" user interface, the ability to type such three key sequences was lost, since the menus became much less extensive. If my memory serves, it was still possible to access a subset of operations using this Alt trick or something similar, but due to the whole restructuring, all the key sequences I had learned and which had become muscle memory over many years were suddenly lost, in some cases replaced by new sequences, in other cases not assignable to a key sequence at all. I would have needed to re-learn how to access all my favorite advanced features of the editor, which would interfere with my work by breaking my train of thought and forcing me to think about the operations of editing and not about the problem at hand. Since I had to get real work done, I did what was most expedient: I downgraded to the last version that included the old-style menu bar and stuck with that, and with a handful of annoying bugs that were subsequently fixed in the newer restructured versions, but never in the older version I was using.

The bottom line is that there's a loss of decades old muscle memory on one hand, and a serious longevity risk on the other: Supposing that ARM architecture caught on for PCs and workstations, if I could find a way to run the old menu bar version of the unnamed editor, say with WINE or some other compatibility layer, I would risk losing the ability to do so if support for such an era of applications (e.g., 32-bit Intel) were ever declared obsolete and removed from said compatibility layer. And even if I wanted to run the newest version of the editor in a new version of Windows in a new ARM computer, or in WINE or some other compatibility layer, I would have to relearn everything, and if I had to relearn everything, I might as well switch to a text editor that doesn't require virtualizing an entire OS just to run it.

So now the question was, out of the many, many editors out there, which one should I choose?

I decided to approach this question as follows: Relearning all of my editing muscle memory would be no easy task. Even if a text editor allowed me to set up hotkeys, or shortcut keys, or key bindings, or whatever you want to call them, every editor works differently and has a different complement of features, so I knew that no matter which editor I chose, I would be in for a learning curve and a period of time during which I would be far less efficient at text editing.

Therefore, my first criteria was as follows: Whichever editor I chose, I wanted that to be the last time. I would put in the hours and the extra effort to learn the new editor's way of doing things, but I wanted to be darn sure, as much as possible without actually knowing the future, that I would never have to go through an editor switch again.

This has several implications:

First, the chosen editor must be free software with full source code available so that its existence will not depend on a business or a specific person.

Second, it must be portable and cross platform, so that if tomorrow's OS is different than today's, the editor comes along.

Third, it must have a large user and developer base with ongoing regular releases so that its obsolescence or death would be unlikely.

Fourth, it must have a track record, meaning it must have existed for a while, to avoid the phenomenon that a hot new thing comes on the scene, becomes hugely popular, and then drops out of style just as quickly.

Once I believed that an editor was likely to survive for the long haul, there were my technical requirements:

It also must be an advanced, fully-featured editor that can help me in all my programming and text processing tasks, making repetitive things as automatic as possible while giving me full control over what ends up in the saved file.

It must offer enough leeway for customization that I could get it to work the way I want it to.

It must be efficient, quick, snappy, and light on resources. When I type a character, it better be on the screen instantly. (No joke: Some text editors are so slow that keys may take a second or more to appear on the screen! This is not only very irritating, it breaks the very first rule I mentioned at the top of this article, that a text editor should not interfere with the user's train of thought. A noticeable delay interferes a lot!)

Finally, it must be an editor I like to use, which is subjective, but ultimately is important.

So I started considering and evaluating text editors, and I considered and evaluated a lot of text editors.

Colleagues suggested many options, from actual text editors to full blown IDEs. Some of the suggestions included: Visual Studio Code, Xcode, Eclipse, Brackets, Atom, Kate, Code::Blocks. I also found and considered various other editors.

Some of these, I eliminated without even trying them because they didn't meet my first criteria (free, full source, portable, and so on). Others, I tried but eliminated because they didn't meet other requirements (including the subjective one in some cases).

As I was trying various text editors (and indeed fully fledged IDEs in many cases), I knew in the back of my mind that there were two more options: Emacs and Vim. I also knew that some programmers considered these two the only options, and that Real Programmers used one of these, and that the Emacs vs Vim question was one of computing's long-standing holy wars. And finally, I knew that they both came from a different time period and were therefore very different from your typical modern GUI application. But other than that, I didn't really know much more about them, and honestly I hadn't really considered looking into them.

I gave a sincere evaluation to Visual Studio Code since it seems to be very popular nowadays. In fact, I tried it, then I tried other editors, then I tried it again, and I repeatedly tried it in between other editors until I ultimately decided that it did not fit my needs for a variety of reasons which I won't take the time to detail here. (After all, this is Why Emacs, not Why Not Visual Studio Code.) I might go on a rant about this some day, just not today.

It was partly my disappointment with Visual Studio Code and a desire to use something as different from it as possible, partly the fact that I had eliminated pretty much every other option out there for one reason or another, and partly just curiosity to see what all the big deal was about, that led me to try Emacs late one night.

This was Emacs 26.1 on Debian 10 Linux somewhere in the neighborhood of six to eight months ago.

I launched Emacs, was met with the default splash screen, and had no idea what to do next, so I ran the tutorial by clicking a link in the splash screen. Within the next hour, I had done enough of the tutorial that I was able to do basic text editing with Emacs's weird and different way of working. I realized that there would be a bigger learning curve with Emacs than with, say, Visual Studio Code or pretty much any of the other options except Vim, but I had seen enough to become intrigued.

Over the following weeks, I used my old proprietary text editor at work, but came home and played around with Emacs for an hour here, an hour there. I will admit that Emacs took quite some getting used to in those first days. Also, a number of things didn't work exactly the way I needed them to, such as automatic indentation and syntax highlighting in C. But something about Emacs told me that I had discovered something special, and something which seems to be a slightly well-kept secret among computing's insiders.

Also, in looking over my criteria for a new editor, I realized that Emacs met all of them:

It is free software. The full source code is available.

It is portable and cross platform. It runs on pretty much every operating system in existence.

It has a large user and developer base. There are countless blogs, articles, websites, videos, and even in-person meet-ups dedicated to Emacs. There are distributions of Emacs like there are distributions of operating systems, ranging from "Vanilla Emacs" (just GNU Emacs without any packages added) to full-featured ones like Doom and Spacemacs. There are countless add-on packages for Emacs, available as anything from snippets of Emacs Lisp (Elisp) on various blogs to packages hosted on several different repositories. It has ongoing regular releases, including not only maintenance and bug fixes but also significant new features.

It has a track record going back to the 1980s in its current incarnation and based upon a concept and code dating to the 1970s. Looking into its track record, it seems to me that GNU Emacs had a bit of a dip in popularity in the early 2000s, where those who had been long-time Emacs users stuck with it, but new kids on the block were adopting other text editors. But it seems that in the last 10 years, give or take a few, GNU Emacs has made a pretty good comeback and its popularity seems to be increasing. The factors involved in this are, I think, the fact that it became a fully graphical application (which still fully supports running in text-based terminals), the availability of several "opinionated" distributions which seem quite popular, and a "killer app": Org Mode. Also, it is far easier today than in its earlier history for users to share information, hacks, tips, tricks, and advice about Emacs.

As far as being an advanced, fully-featured editor, Emacs is pretty much the definition of advanced and fully-featured. As for the ability to customize it, the variety of available packages, both built-in and from other sources, proves that Emacs can be made to do literally anything.

As for efficiency, it has been quick and snappy in my (so far limited) experience. I have read that Emacs has trouble with certain things, like too-long lines, and in an experiment, I found that to be true. That is irritating and, from what I understand, a long-standing problem, but hopefully it'll be fixed some day. As far as "vanilla" Emacs out-of-the-box, everything seems plenty quick and snappy to me. (I have been using 26.1 and 27.2 on two different Linux distros, but note that 28.1 includes a native compilation feature that is supposed to speed things up considerably.)

Finally, regarding my subjective criteria, I find Emacs fun to use. Yes, there's a very steep learning curve in the very beginning and based on everything I've seen so far, the learning curve never levels out, but neither do the rewards. Yes, it behaves quite differently than your typical modern GUI application. Yes, it takes effort and investment to get up to speed with Emacs. But I enjoy using software that opens up a world of possibilities, and which respects my intelligence rather than insulting it. I am confident that I have found an immensely powerful tool which will pay dividends in the long run.

On this page, I plan to gradually document my adventures with Emacs, including more details about how I got started with Emacs, tips, tricks, and my own notes on how to do various things... Check back for more!

Updated on April 24, 2022: Fixed a few grammar errors and improved readability and clarity in a few places.

Updated on May 24, 2022: Improved wording/clarity a little bit more.

Updated on August 10, 2022: Fix misspelled word.

What About Vim?

April 24, 2022

In the previous section, I said that while evaluating various text editors, I hadn't considered Emacs or Vim and didn't know much about them.

In fact, I did know a little bit about Vim because it (or its predecessor, Vi) has come pre-installed on just about every Unix-like operating system for as long as there have been Unix-like operating systems. How much, or how little, did I know about Vim? Just the absolute minimum in terms of survival skills: I knew how to use the h, j, k, and l keys to move around, press i to get into Insert mode, type stuff, and then press Esc followed by :wq! to save and exit. That just about summarizes the full extent of my knowledge regarding Vim for the past approximately 20 years.

It was not until after I began to evaluate Emacs that I wondered if I should look into Vim, so I did.

I discovered that in addition to the Vim that runs in a terminal, there is also gvim, which runs in a graphical window complete with a modern menu bar. There is also Neovim, which, as I understand it, is a rewrite of Vim.

I decided to give Vim a fair evaluation and in fact I went so far as to read the entire Vim manual from cover to cover. Much of what I read there looked pretty good. What I liked the most about Vim is that it seems designed to accomplish things with minimal hand motions.

I was amused to learn about Vim Golf, which is a game people play with Vim to see who can effect certain textual changes with the least number of keystrokes, similarly to the way golf, the sport, is played. I also found it amusing that some Emacs users out there have made it a point to demonstrate that some Vim Golf solutions can be done in fewer keystrokes with Emacs than with Vim (example: this page at Mickey Petersen's Mastering Emacs site).

Ultimately, though, I concluded that Vim is not the right editor for me and for a reason that Vim users have probably heard time and time again: I just can't seem to get accustomed to its modal editing workflow.

Also, although I can see that it offers a lot of hidden power, I felt like it would really tax my brain to make use of it, so that I would have to think entirely too much about the process of editing rather than focus on the problem at hand. For whatever reason, Emacs just feels like a better fit for my way of thinking.

Exciting Times Ahead!

October 26th, 2022

Two very BIG and exciting pieces of Emacs news landed within the last three weeks:

The first one, chronologically, is that tree-sitter support is slated to be included in Emacs 29. Briefly, tree-sitter is a super fast parser that can turn source code into a syntax tree.

What's so exciting about that? Up until now, the font locking in Emacs (also known to non-Emacsers as syntax highlighting) has been implemented via regular expressions, with workarounds built-in to deal with performance issues and the like (such as font locking taking too long).

I have noticed that sometimes, when in the middle of an intense code hacking session in Emacs, the font locking seems to get discombobulated, which is why I have documented elsewhere on this page the command to "fix" font locking by re-fontifying the buffer (M-x font-lock-fontify-buffer). Granted, I am currently using an older version of Emacs, 26.1, which was released over four years ago at this writing, and it is certainly possible that things have improved since then.

But back to tree-sitter. Mickey Petersen of Mastering Emacs fame wrote an article about tree-sitter, which was recently updated for Emacs 28. In the article, Petersen documents the major challenges of implementing parsers for syntax highlighting, such as having to deal with incomplete code as it is being written and edited. It's worth a read to get a better idea of what tree-sitter is and what it will hopefully do for the future of syntax highlighting, er, I mean, font locking, on Emacs.

Some interesting references (tree-sitter):

The second exciting piece of BIG news is that Eglot is merged into Emacs master and so, I think, will also be in Emacs 29. Eglot, or as I've also seen it called, eglot or M-x eglot, which stands for Emacs Polyglot, is a Language Server Protocol (LSP) client for Emacs.

LSP is a protocol that allows an editor like Emacs to communicate with a language server, a piece of software which understands a certain programming language and can provide the editor whatever information it needs to be helpful for programming, such as code completion. Here is the LSP landing page.

The other major LSP client for Emacs is called LSP Mode. Debates about Eglot vs LSP Mode are like all the other holy wars of computing: Emacs vs Vim, Linux vs BSD, et cetera, so I will leave it up to the community to debate which one is better, cooler, and so on.

What I can say for sure is that from the outset, Eglot was developed with an eye toward integrating it into Emacs itself, including a requirement to sign copyright assignments for non-negligible contributions. It seems the long-anticipated integration is happening now.

Some interesting references (Eglot):

In summary, the combination of tree-sitter for excellent font locking, together with Eglot for ultra-modern language-aware IDE-like features in Emacs, included in "Vanilla Emacs" with all its power, flexibility, and decades of built-in experience, should make Emacs 29 an exciting release indeed!

Useful Stuff

July 31st, 2022

This section is a quickly slopped-together listing of stuff I refer to every so often. Hopefully I'll get around to organizing the information better in the future, but for now, here it is:

Quick Fixes

Emacs font locking gets discombobulated: M-x font-lock-fontify-buffer

Key Bindings

Jump to first non-whitespace char in line: M-m

Repeat macro till end of file: M-0 C-x e

M-x shell (a Comint mode)

M-p, M-n - walk through history ring.

M-r - Reverse history I-search / regexp.

C-M-r, C-M-s - Walk through history I-search ring.

C-c C-x - Repeat order of history commands that come after the last one run.

C-c . - Insert Nth argument (like M-. in GNU Readline).

C-c C-l - Show Comint's history in a completion buffer: TAB to navigate, RET to select.

C-c M-r - Search for lines starting with current command up to cursor.

C-c C-o - Delete output of last shell command.

C-C C-s - Save output of last shell command to a file.

C-c C-r - Move point to beginning of the output.

C-c C-c - Ctrl+C twice sends Ctrl+C to the process (bound to comint-interrupt-subjob).

Miscellaneous

Revert a buffer: C-x C-v RET runs find-alternate-file, prompting for a filename with the current buffer's filename pre-filled. Pressing RET reloads the file from disk.

Copy current filename: Either: (1) C-x C-v (find-alternate-file) → C-a (move-beginning-of-line) → C-k (kill-line) → C-g (keyboard-quit), Or: (2) C-x C-f (find-file) → Down Arrow (next-history-element) → C-a C-k C-g.

Open directory containing file in dired: C-x C-d RET.

Increase or decrease indentation interactively: C-x <tab>, then left/right for 1 space, S-left/S-right for 1 tab.

Emacs Regular Expressions

Emacs regexp (regular expressions) search and replace:

CodeDescription
^Beginning of line
$End of line
.Any single character (like ? in filenames)
.*Any group of zero or more characters (like * in filenames)
\<Beginning of a word
\>End of a word
[] Any character specified within the brackets, e.g., [a-z]
[]*Like above but matches zero or more occurrences

References and External Resources

This section last updated December 5th, 2024.

This list of resources is nowhere near exhaustive. Primarily, I maintain this list for my own convenience, so I can find resources when I need them. Hopefully you'll find something useful here, too.

Help and Wikis

Important Articles

Community

Meta-blogs

Blogs

Some of these blogs are focused entirely (or almost entirely) on Emacs. Others discuss Emacs moderately frequently but include other subjects as well.

Video

Historical Documents

Books

In alphabetical order:

Emacs Lisp (Elisp)

Emacs Distributions

Like a true operating system, Emacs comes in various flavors or distributions, besides the official software, affectionately called "Vanilla Emacs" by the community. Some of these are listed here, in alphabetical order (excluding the word Emacs).

Back to main page

Send feedback to: the name of this blog at mail dot com.