Irreal

Many of us run Emacs on multiple platforms. Some, like me, simply run several OSs on our various computers, and some have one system type at work and another at home. Regardless, we all want a one true Emacs configuration that adapts itself to whatever system it’s running on. Using a single configuration file means that you can make additions or changes and have them reflected across all your systems. Trying to keep such changes synced across several configuration files will, believe me, end in tears

Over at The Emacs Cat, olddeuteronomy, who deals with three different operating systems, explains how he handles a single Emacs configuration for all his systems. The key to all such systems is using the Emacs variable system-type to discover what OS you’re currently running on and then conditionally executing system specific settings. Since most settings don’t depend on the system type, this makes it easy to adjust general configuration items and have them take effect across all the systems at the same time.

Rather than clutter up my init.el with a bunch of conditionals, I use the following code at the start of my init.el:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Pull in system and platform specific configurations                    ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;; Just keep on going if the requisite file isn't there.
;; Manipulations in second load is for "gnu/linux" → "linux"

(load (car (split-string (system-name) "\\.")) t)
(load (car (reverse (split-string (symbol-name system-type) "/"))) t)

The first statement loads a file with the same name as the computer’s name. The second loads a file with the name of the OS type. That way I can have a file, named darwin.el, with all the macOS specific settings and another for Linux specific settings. Similarly, if I need some machine specific settings—such as screen size—I simply put them in a file with the machine’s name and the settings get applied automatically. I don’t remember where I got the idea for that strategy but I’ve been using it for a long time and it works well for me.

Whatever method you use, if you’re dealing with more than one machine you probably need to adjust your init.el to handle them all seamlessly.

Over at the Emacs subreddit, kudikarasavasa asks a question dear to the hearts of many of us: How did you start living inside Emacs permanently? He says he keeps hearing people say they live inside Emacs and the idea seems appealing to him but he doesn’t understand how people made the journey. Did they start out to live in Emacs or was it just something that happened along the way?

Of course, it’s the answers not the question that are interesting. There are all sorts of stories. The majority of them say that living in Emacs is just something that happens after you’ve been using Emacs for a while. The usual story is something along the lines of starting to use Emacs, liking the interface, and moving all the easy tasks, coding, writing, note taking, agendas and TODO lists, and maybe even version control via Magit, into Emacs. Later, these people find, as I did, that writing and editing in other applications has become painful.

So they move “harder” applications—like email and RSS readers—into Emacs. Pretty soon, they start thinking, “why should I have to go a separate app to play music?” and they move their music playing into Emacs. Before you know it, they’re doing everything except, perhaps, browsing from within Emacs. Like me, they probably have a couple of tasks that they use other apps for—calendar, texting, and reminders for me—and that remain outside the Emacs sphere but essentially everything else is done from the comfort of Emacs.

Some of the other people are a bit more hardcore. I especially liked this quote:

The alternative journey is you read a lot of stories about Lisp, get hyped about Lisp machines, figure out that Emacs is the best you can actually get, and decide to run with it as far as you can.

I can relate.

It’s worth reading all the comments because there are several useful suggestions for dealing with things like shells and remote editing. As this post shows, it’s pretty easy to move the majority of your computer tasks into Emacs. It’s a really interesting discussion and well worth spending a few minutes reading.

Chris Maiorana has just announced the release of his Emacs for Writers handbook. It’s a 22 page handbook for the writer who would like to escape the confines of “word processors” like Word and its ilk. The handbook doesn’t assume any knowledge of Emacs on the part of the reader but explains how to start from scratch.

After a quick summary of basic navigation commands, Maiorana covers the fundamentals of writing with Org mode. That’s important because by using Org it’s easy to export your writing to whatever format you need. Maiorana concentrates on the ODT export because most publishers these days want to receive Word documents.

Maiorana doesn’t explain how he uses Emacs for his writing; he just explains how to use Emacs so that readers can develop their own style of working. Along the way he covers using abbreviations, word counting, and the installation of packages. He doesn’t say much about packages and the types of things that are available for writers but there are a lot of resources that cover that.

The handbook is offered on a “pay what you like” basis but no matter what you want to pay—even nothing—you’re going to have to provide a credit card number. Still, it’s nice to support efforts like this so even small contributions can help.

If you have any Emacs experience at all this handbook probably won’t tell you anything you don’t already know. If you’re a beginner and want to experience the joys of unfettered writing and editing without an opinionated work processor insisting on your doing things its way, take a look at Maiorana’s handbook and fire up Emacs. It’s not nearly as difficult as some would have you believe to get started, and as you learn more your writing efficiency will improve far beyond what’s possible with a word processor.

Over at the Emacs subreddit, Informal-Silver-2810 says he’s been a Vim/NeoVim user for the last 20 years but decided to try Emacs so he committed himself to a month of using only Emacs. As part of that experiment, he asked the Emacs subreddit what advice they have for a new Emacs user.

The thing that stood out to me was how varied the advice was. Some folks suggested starting with vanilla Emacs, others said start with Evil mode but not packages like Spacemacs or Doom. Still others suggested starting with Spacemacs or Doom or perhaps one of other starter packages.

You have to feel sorry for Informal-Silver-2810: the advice he got included just about every possibility. On the other hand, that probably means there’s no royal road to learning Emacs and that everyone has to discover their own best path.

My own path worked well for me and looking back, I can’t see that any other path would have been better or even as good. As a Vim user I was all in on modal editing and—after more than two decades—Vim’s keybindings were burned deeply into my muscle memory. Nevertheless, when I finally took the plunge, I just jumped into vanilla Emacs and didn’t bring any Vim habits with me. Except, that is, for that muscle memory. For a long time I would do things like use Ctrl+k to move up a line. It almost looks like it’s doing the right thing so by the time I realized what was happening, I had deleted several lines. Thank goodness for undo.

A couple of the commenters had stories like mine but most other strategies were represented too. It seems to me that the best answer to Informal-Silver-2810 is to just feel your way and do what seems easiest for you.

Over at the Emacs subreddit, Cultural_Mechanic_92 asks How did you become an Emacs power user? It is, I suppose, a reasonable question even if the answer is pretty obvious. The comments are interesting but basically boil down to “you’ll learn by doing”. Of course, the advice is a bit more nuanced: you increase your skills little by little by practicing with Emacs, learning to configure it, and making the tool your own.

It was sort of interesting to read the answers but what struck me was the meta-question of what does it mean to be an Emacs power user and how would you know if you are one. In terms of longevity, I would rate myself as intermediate. I’ve been using Emacs for about 17 years and while that may seem like a long time, plenty of others have 30 or more years in.

In terms of skill, it’s harder to assess. Certainly I can be said to have at least journeyman status and perhaps more but as any experienced Emacs user will tell you, there’s always something else to learn—indeed, hardly a day goes by that I don’t learn something new— so how do you know where you are on the road to power user?

If by “power user” we mean “able to solve virtually any problem that naturally fits into Emacs” then I’m probably a power user. If it means being able to solve any problem that fits in the Emacs sphere, then probably not.

What do you all think? What does it mean to be an Emacs power user? Is it entirely subjective or can we say “be able to do everything on this list and you’re a power user”?

Over at the Emacs subreddit, iLemming has an interesting video that explores two packages by thanhvg for reading reddit and Hacker News from within Emacs. The two packages are emacs-reddigg and emacs-hnreader.

Both packages give you a nice Org buffer with each article as a heading and the rest of the content below. Watch iLemming’s video to see them in action. It’s also pretty easy to customize them as iLemming shows by providing custom search functions. Again, take a look at the video for more details.

I like these two packages but, sadly, they don’t fit into my workflow. I never read reddit or Hacker News directly. Rather, I get their content through elfeed, which has a similar user interface and look. Of course, elfeed is RSS based so I often have to follow the link to get all the content. Since I have WebKit hooked into elfeed, my actual workflow just shows we the original Web pages directly as I view each entry.

Of course, lots of people do read reddit and Hacker News directly, and for them these two packages are ideal. You can follow both sites from the comfort of Emacs. If you’re one of those people, take a look at iLemming’s video and see if they might be right for you.

Just in case you haven’t heard enough whining about Emacs not having “modern” keybindings, arthurno1 over at the Emacs subreddit has a long post on possible ways to reconfigure Emacs to get them. It’s an interesting post because arthurno1 actually considers ways to solve the problem rather than just complaining that Emacs keybindings aren’t what he’s used to¹.

The problem turns out to be more difficult than you might think. It probably explains why there isn’t a set of “keybinding themes” similar to the display themes that we have.

I should be more sympathetic to those wanting Emacs to use conventional keybindings. After all, I’ve admitted several times that I have a hard time using multiple keybindings. But when I thought about it, I realized my problem is with using multiple keybindings for they same type of application. For example, I would have a hard time using both Emacs and Vim, even though I know them both well because my muscle memory would cause me to use the wrong binding for a given operation. I have no problem using different keybindings for different apps. So, for example, it doesn’t bother me at all to use Ctrl+s for search in Emacs and ⌘ Cmd+f for the same operation in Safari. Of course, since I mostly live in Emacs, even different keybindings among applications isn’t much of a problem.

I suspect, though, that a lot of this yearning for “modern” keybindings really means, “I want it to be like VS Code” or whatever other editor they’re used to. For those people, I can do no better than to channel Dennis Ritchie: If you want VS Code, you know where to find it.

Some folks like to see a visual indicator of the file type in file listings. In Emacs, this usually means in the Dired listings. Probably the best known way of doing this is the all-the-icons-dired package. It has a set of beautiful icons that it adds to each entry to identify the file type. The problem, from some people’s point of view, is that all-the-icons-dired is a third party package and may, in turn, require the installation of additional font files.

James Dyer likes the idea of a visual file-type indicator but doesn’t like having to deal with external packages and their dependencies. His solution is a light-weight version of a visual icon package. Actually, it’s not even a package, just a bit of code that you can add to your init.el to implement his solution.

The “icons” are just standard shapes that are in virtually all font sets. They aren’t as pretty as those in all-the-icons-dired but they do serve to provide a visual indicator of file type. The shapes are listed in a simple variable so you can change them to suit your needs.

Being an old-time guy who spent a lot of years working on text terminals, I have no problem distinguishing file types by their extension—which is, after all, what all these packages do—so I don’t feel the need for such a solution but if the idea appeals to you and you don’t want to deal with dependencies, give Dyer’s post a look. It’s simple to try out and if you don’t like it you can just delete the code from your init.el.