Irreal

As those of you who have been around for awhile know, Irreal has a fascination with fonts for Emacs. I most recently wrote about them here. But, all those posts have been about coding fonts. Today, I want to talk about proportional fonts.

You can, of course use proportional fonts for coding but it’s mostly Rob Pike and his disciples that champion that. Still, most of use proportional fonts for everything else. Recently, Charles Choi even convinced me to write my posts in a proportional font.

This post was inspired by an article on the Atkinson Hyperlegible Font. It’s a font developed by the Braille Institute for low vision readers. Those of us without vision problems should also take notice because the font really is easy to read and, most importantly, it’s easy to distinguish among those hard to discern characters that I use to decide if a font is acceptable for programming use.

It’s usually not as important to distinguish them in a prose environment but most programmers are anal about things like that and would prefer having clarity in all the text that they read. Take a look at the Atkinson Hyperlegible Font article to see it in action and to see how well it distinguishes among all those problematic characters.

For me, one of the worst problems with proportional fonts is telling the difference between capital I (eye) and lowercase l (ell). As I write this in Emacs using my proportional font, those two letters look virtually the same. That’s a problem I wouldn’t have if I were using Inconsolata, my coding font. Atkinson Hyperlegible makes the difference clear. That alone is worth adopting the font.

You can download the font for free but the Braille Institute would appreciate a contribution. This seems like a great font and is worth a contribution to help the Institute in their work.

One of the activities that Irreal encourages is the sanding down of friction points. Despite that, I’m almost always surprised when I do automate some routine task and wonder why I waited so long to do it. If you’ve been around Irreal for a while, you’ve seen me write about that several times.

Over at dyerdwelling there’s a handy post on how to sand down one set of friction points. His particular friction point is creating directories and files from within Dired. That’s possible, of course, but the various completion engines can trip you up but substituting your choice for an existing file or directory with a name that matches in the fuzzy sense.

His solution is to define two new functions that ask for the directory or file name without invoking completion. The code is simple, short, and easy to understand. If you use Dired to creat files and directories, take a look at this post

Paul E. Johnson is a member of the Political Science Department at the University of Kansas. As such, he’s not a canonical Emacs user but he has a provacative set of slides that suggests that, in fact, Emacs doesn’t have a steep learning curve. Or, at least, it needn’t have one.

His thesis is that one can use Emacs with more or less “standard” keybindings by using the arrow and other special purpose keys and by turning on CUA mode to make Emacs input more like “modern” apps.

That’s all true, of course, but it strikes me as riding a bicycle with training wheels. Yes, you can ride around and do bicycle-like things but you can’t really call yourself a bicycle rider. Even Johnson recognizes this and notes that you’re going to want to learn at least some of those native Emacs commands.

When I learned to ride a bike, I didn’t use training wheels and I don’t recommend them for new Emacs users either. Sometimes you just need to grasp the nettle and push through the pain. The benefit is that at the other end you can ride a bike or use Emacs well.

Still, Johnson has a point. It’s possible to start using Emacs without having to learn all those bespoke keybindings. The question is whether that’s the best path forward. I think not but obviously others disagree and I’m willing to stipulate that they may be right, at least for some people.

A couple of weeks ago, I wrote about Protesilaos Stavrou’s excellent post on triggering an Emacs popup from anywhere in your system. It’s perfect for Org capture and other things you might want to do when you’re in some other app. I have something similar specialized to Org capture and Phil in the comments said he also has a few bespoke popups. The advantage of Prot’s framework is that it’s easy to invoke any Emacs command from outside of Emacs.

Grant Rosson liked the idea but found that Prot’s Linux based code didn’t port directly to macOS and he presented the code for the minimal changes required to get things working on a Mac. Despite what some folks seem to think, Mac users are a significant portion of the Emacs community so his changes are welcome for those of us using macOS.

Rosson gives some examples of commands other than Org capture that may give you some ideas. What I really like about Prot’s and Rosson’s frameworks is that they help you move as many chores as possible into Emacs. A lot of that simply boils down to being able to enter text in a reasonable—by which I mean Emacs—environment.

If you’re a Mac user and interested in being able to popup a temporary Emacs frame to do whatever you need to do, take a look at Prot’s video and Rosson’s post. You’ll be glad you did.

As every Irreal surely knows, I’m a die hard Emacs user but I was, for a long time, a Vim user and still consider it one of the two best editors. It’s long been my view that Emacs and Vim serve two different constituencies and aren’t really the same type of application. The TL;DR is that Vim is for people who want a small, fast, editor that excels at editing and doesn’t bother with anything else. Emacs, on the other hand, is for people who want a unified operating environment that—sort of—recapitulates the Lisp Machines.

Nicholas Bernstein is a committed Vi/Vim user who more or less agrees with me. Like me, he thinks that Vi/Vim and Emacs are distinct types of applications that serve different needs. He has a nice nice video that discusses this and makes the case that Emacs is all about providing a consistent interface for text based applications.

I think that that’s true but doesn’t tell the entire truth about Emacs. Yes, it does provide a consistent interface for text but it offers much more. It is, as I’ve often said, a light weight Lisp Machine that provides an integrating environment for all your computing needs. If you’re happy with a text-centric browser, Emacs can be the center of all your needs. Even if, like me, you use a standard browser for the dealing with the Web, Emacs can still provide almost everything else.

As I’ve said before, I spend almost all my time in either Emacs or Safari. I have to say, it’s a pretty nice environment. Bernstein makes the same case from the point of view of a Vi/Vim user.

As most of you know, Irreal doesn’t think much of editor-connected bling. We much prefer simple efficiency to flashy accouterments that, in the end, simply get in the way of a decent editing experience. That’s true even though they can, arguably, make it easier to get started with a new editor.

It feels a little odd, then, to be writing favorably about these reformatted Emacs documents that, while they have the same content as the official documents, have been reformatted to look a bit nicer and, more importantly, be easier to navigate. It’s probably not accurate to describes the results as “bling” especially since the point of the change is better navigation.

The two major changes are a sidebar that essentially recapitulates the table of contents so that it’s easy to get an overall view of the document and an improved search function that makes parsing the search results easier.

Irreal does think that these documents are a worthwhile addition to the Emacs document stack and wouldn’t object if, arguendo, they were adopted by GNU. Still, the Irreal bunker is probably going to continue to use the “official” documents but doesn’t object if others make a different choice.

The documents that are available are:

• The GNU Emacs Manual
• The GNU Elisp Reference Manual
• The Org Manual
• The AUCTeX Manual
• The Magit Manual

Take a look at one or more of them and see what you think.