Irreal

Xah Lee has an interesting post that I hadn’t seen before even though it’s originally from 2014 (since updated) and mentions a post of mine. The post is a discussion of whether it’s better to have a single large Emacs frame with multiple windows or multiple smaller frames. Lee makes the case that it’s more efficient to have two window-sized frames rather than running Emacs in full screen mode and having two windows in the frame.

When Lee says something about efficiency with respect to Emacs, it’s worth paying attention. In the end, you might not agree but Lee takes this stuff seriously and generally studies the alternatives to determine which is best. If you haven’t read his post, you should do so now so that you understand the context.

Lee’s argument, as I understand it, is that switching between windows in a single frame is suboptimal because various Emacs operations will destroy your windows configuration and using something like winner-mode to restore your window configuration is too much trouble. He prefers to let the OS handle the sizing and position of frames and configures a set of convenient keys to switch to Emacs and move between frames. He then feels free to split either frame temporarily into multiple windows and restore to the single window, presumably with something like Ctrl+x 1, when he’s done.

I disagree with his workflow but not emphatically. I think the multiple frame idea has merit but I don’t see how it’s better—or even as good as—multiple windows. If you divide a frame into more than two windows, you’re still going to want an easy way of switching between them. As I wrote in the post that Lee linked, ace-window is the ideal way to do that. And I don’t see how using winner-mode to restore your default window configuration is any harder than using delete-other-windows.

Still, most of this boils down to individual preference and there’s not really a right or wrong answer. All that said, my actual workflow is not that different from Lee’s. I have an OS key to switch to Emacs which is usually running in full screen mode with two windows. Sometimes I need to split one of those windows temporarily and when I’m done I just call winner-mode to restore things. Sometimes (usually when I running elfeed in a full screen window) I do fire up another frame. It opens in full screen mode but doesn’t, of course, show the original frame. When I’m done, I destroy the new frame with Ctrl+x 5 0 and I’m back to where I was.

I could easily use two frames with this method but then I’d have to worry about two ways of switching to the window I wanted rather than just using ace-window. What do you think? In particular, if you’re using the two frame method, what has been your experience?

Xah Lee has a nice video on abbrev mode that shows you a couple of ways to use the facility. Abbrev-mode is built in so you don’t have to install any packages: you can just start using it.

Lee covers both ways of using abbrev-mode. There’s an “official” way that he’s documented here and the easier “Elisp” way that he’s written about here. The video covers both methods so you can watch them in action and decided which you prefer. The difference really only affects how you edit and maintain the abbrev file; actual use is the same.

Unlike Lee, I prefer to use yasnippet but, as always, Emacs lets you have it your way. I agree with Lee that whichever system you prefer you should definitely be using one of them or, perhaps, both.

I also agree with Lee that the simpler “Elisp” way is easier and better. With that method you just edit a simple text file as usual and don’t have to remember a bunch of commands and their key sequences to maintain your list of abbreviations.

The main thing I don’t like about abbrev-mode is that it gets triggered automatically when you type an abbreviation followed by a space. I don’t like things happening automatically when I’m editing text so I prefer the yasnippet way of triggering the expansion with a Tab after the abbreviation.

As I said, whatever your preferences, you should be using one of the systems. They really do make your life easier even if you use it only for implementing shortcuts to phrases you use all the time: imt → in the mean time for instance.

The video is 10 and a quarter minutes so it should fit easily into a coffee break.

Added While Waiting for Publication:

While this post was sitting in my READY queue, I stumbled across a reddit post by rmberYou that reminded me of one abbrev-mode application that yasnippet can’t do: the automatic correction of common spelling errors or typos that you make. Suppose you often misspell “receive” as “recieve.” If you make recieve an abbreviation for receive, it will automatically get corrected for you each time you type it. This is one place where even I would want the translation to happen automatically.

UPDATE [2018-06-20 Wed 11:20]: Deleted superfluous “one.”

I’ve had this topic in my blog queue for a couple of weeks but I noticed literally scores of tweets pointing to the post in question. That was enough to make me forego my own post on the subject but on rereading the original post, I realized there are some good ideas in it regardless of what’s going on with the tweets.

The post, by Dylan Kirby of MojoTech, discusses to problem of internationalizing text strings in an application that will be used in more than one country. Kirby discusses the problem in terms of the React framework but almost exactly similar problems occur anywhere you need internationalization. I’ve done my share of that in C where we used the GNU gettext library. It’s always a pain and, truth to tell, I avoided working on it whenever I could slough it off to my colleagues. I’m a bad person, I know.

Regardless, Kirby and his colleagues were stuck with doing it and he noticed that it was mostly repetitive work. They used Google Translate to provide a first order translation that was later refined by a human translation service so a first hack at the translation could be automated along with the rest of the mechanics.

You can get the details from Kirby’s post but the most important lesson from his account for me is that it serves as an answer to why you might prefer an Emacs “lisp-machine-like” environment to the pure editing environment of Vim. Kirby’s problem is representative of a common class of problems that are easy to automate with Emacs. My Vim-foo is rusty enough that I don’t see an easy way to do the same thing in Vim, especially the querying of Google Translate. You can argue that you don’t want to read emails in Emacs or use it to listen to music but, believe me, if you have to deal with internationalization, you’ll be happy to have a way of automating it as much as possible. It’s just one more reason that I’m glad to be an Emacs user.

As you’ve probably heard, Emacs 26.1 has replaced the old linum-mode with a faster and less cluttered implementation. I almost never need or want line numbers so they’re normally turned off but for the occasional times when they’re useful, I have a custom key sequence to turn on linum-mode on a buffer basis. I replaced that call to the new facility by calling display-line-numbers-mode instead. They look a lot nicer and don’t slow things down as much for large files but I still don’t use them much.

Others disagree. I just watched a Xah Lee video on Abrev mode (I’ll be writing about that later) and noticed he had them turned on globally, presumably with global-display-line-numbers-mode. David Crook also likes to turn them on globally but he didn’t want them to display in his neotree buffer. He’s posted what he had to do to stop them from cluttering up his neotree buffer. It was harder than you might think so if you have the same or similar problem, you should take a look at his post to see how to fix things.

If you’re one of the people who likes line numbers in your buffers, you’ll appreciate how much the facility has been improved. Just another example of how vibrant our developer community is and how far from moribund Emacs is, no matter what the naysayers tell you.