Further remedial keystrokes

As I’ve mentioned before, the first systems on which I used Emacs had keyboard support that was spotty-to-nonexistent for anything but the most common keystrokes.

Consequently, I learned to use ESC for a lot of stuff where you’d use Meta. For most of those things I’ve retrained myself, but until I was actually reading the GNU Emacs Manual, I didn’t know that you didn’t have to hit ESC to do a numerical argument.

So where I’ve often done ESC 5, say, to do a numeric argument to a function, I’ve now learned that I can simply do M-5, which is more like a single keystroke.

I do expect it’ll take a bit to train myself out of my existing habit, but I’m hopeful.

Closing down the competition

Well yesterday I talked about C-o (open-line) that opens up additional lines beneath the line you’re currently on, and how little I used it.

A related key that I use even less, but could see more opportunity for, is C-x C-o (delete-blank-lines), which collapses repeated lines of whitespace into a single line.

The first thing I find myself wondering, though, is “Why C-x?” It seems to me that most other commands like this—variations on a shorter set of keystrokes—use the C-u prefix to say, “do the opposite-ish”.

That aside, I’m going to try and keep this keystroke in mind, because it seems like something I will find a use for, if only I can remember it.

Opening up your document

I’m actually a bit of a fan of whitespace in code. I know a lot of people who…are of a different opinion, to say the least. Perhaps it’s because I don’t have some of the more sophisticated code-motion keys down in Emacs, but I like to have the whitespace to break up semantic units and help me understand how lines of code are interrelated.

So it’s surprising that I haven’t ever really cottoned to C-o (open-line).

Actually, that’s not 100% true—in the readline library that underlies the history system in the bash shell, I use C-o a lot; it is useful for when you have a repeated series of commands you want to cycle through again, you can find the first command in the series and then step through with it.

But in Emacs, I’ve never used it much.

However, what I do find myself doing a lot is C-q (quoted-insert) C-j (newline-and-indent) in the mini-buffer, during search-and-replace sessions. And for that, C-o may be, at times, an easier option. So I’ll try and adopt it, and see how it goes.

Weekly Wrap-up #1

This blog is supposed to be about what I’m learning and how the process of refining my use of Emacs is going, so each week I’ll be looking at what I wrote about in the past week (or perhaps earlier) and assessing how much I’ve been able to change my habits or otherwise make use of my new knowledge.

So this first week has gone pretty well—using M-g M-g (goto-line) instead of M-x goto-line has come up a couple of times and I’ve remembered the new way of doing things, and similarly C-/ (undo) for undo. The change back to the prior handling of line-move-visual hasn’t come up as much as I expected—I have a much wider terminal these days, so it’s less of an issue—but I’m nonetheless glad to have made the change back.

The one thing I’ve not internalized, and that I’m not sure I’m likely to internalize, is using C-LEFT (left-word) and C-RIGHT (right-word) for by-word cursor motion. The benefits versus M-b (backward-word) and M-f (forward-word) just don’t seem to be there—it turns out that for me, keeping my hands on home row outweighs the awkwardness of doing it all with one hand.

I’ve actually done a lot of other stuff this week, too—I’ve started using org2blog for all of my blogging (and will write about it shortly), reorganized my init process, started using ido-ubiquitous, and a few other things. But, for this week, this is the end.

The existential pain of naming Backspace and Delete

When I first started using uEmacs, one of the most confusing things was the fact that the adaptation had not been entirely completed, or at least on my platform (an Atari ST), the keyboard mappings were not entirely idiomatic—they hadn’t kept up with the differences between VT-100-style keyboards and, well, everything else.

I think this explains why I got very habituated to the alphabetic keys for deleting stuff, but don’t have the non-alphabetic keys as deeply ingrained.

So, while C-d (delete-char) for deleting the next character is definitely embedded in my fingers, and I use C-k (kill-line) like an old friend, and even M-d (kill-word), I still have to think hard before using M-DEL (backward-kill-word)—to the extent that I am far more likely to do M-b to move back and then do M-d to delete the words I just backed up over.

So I’m trying hard to get used to using M-DEL (which is Alt-Delete on most PC-flavored keyboards), because it is actually a fairly common operation, and I want to be more fluid with it.

I thee undo

For years I’ve been using C-x u (undo) for undo. As much as I use it, though, I really need to get C-/ (undo) under my fingers.

I never remember revert-buffer, since I rarely get myself to the point where I want to just nuke everything from orbit—so perhaps it’s not surprising I rarely think about it.

In fact, I think the interface of GNU Emacs’ undo facility is one of the few places where it falls dramatically short of its potential. I really don’t know what sort of facilities that other editors have, but given the way that Emacs stores the history, I’m surprised that the baked-in functionality provides no way to access it more efficiently—I mean, there’s not even an explicit redo command, you have to just undo your undoings, ad infinitum. I’ve often accidentally started redoing things when I hit an injudicious key, etc.

Poking around EmacsWiki, I find a reference to UndoTree, which looks like just what I might like. Perhaps I shall package it up and see how well it works. If so, I’ll report back.

Visual versus logical lines

In GNU Emacs 23 the default line-movement behavior changed with regard to wrapped lines.

Not that I realized it at the time, entirely—like not realizing that I not only knew M-f (forward-word) and M-b (backward-word), but used them every day, I was so habituated to the prior behavior that I couldn’t articulate what had changed, I just knew something was different that was annoying me to no end.1

It was only when I found a reference to line-move-visual in the GNU Emacs Manual, that I realized exactly what it was that had changed—and, more importantly, how to change it back:2

(setq line-move-visual nil
      track-eol t)

line-move-visual, when set to a value other than nil, indicates that if there was a line on the screen, the cursor keys should move through it, even if it was the wrapped continuation of a prior line. Emacs’ prior behavior was that the cursor keys would move the cursor based on the basis of “logical lines”—that is, the lines as determined by the presence of line-ending characters. So if you had a “logical line” that spanned three lines on screen, when you hit C-n (next-line) on that line, you ended up three lines down on screen.

If I hadn’t been habituated to this, I probably wouldn’t care—I don’t really think one behavior is significantly better than the other. But the prior behavior is what I’m used to, so I’m going to change it back.

At the same time, I’m setting track-eol to t so that when I move the cursor up and down while at the end of a “logical line”, the cursor will stick to the end of lines, no matter how long or short they are. This sort of stickiness is another behavior I’m used to at a fairly low level.


1 I am amused to find that no less than Mark Crispin, developer of the IMAP protocol agrees with me.

2 This is, ultimately, one of the reasons I enjoy emacs—more than any other editor, I suspect, if you don’t like something, you can probably change it. GNU Emacs is, as I used to tell people, “a programming environment cleverly disguised as an editor.”

Just getting around

The this blog had its genesis when I sat down to read the GNU Emacs Manual while we were travelling over the holidays—I figured I could skim it, maybe pick up one or two new things, but, really, it would mostly be just speed-reading.

What it actually proved was that I had never tried to read the manual recently, perhaps ever. I would stumble across basic stuff I feel like I should have known all along, and then an hour or two later would have to work very hard to remember what it was that I had stumbled across.

I have come to realize I retain things better if I write them down—I still don’t understand how I got all the way through college, since I never took notes worth a damn. So this is my public notebook.

While I know M-f (forward-word) and M-b (backward-word) at such a low level that I thought I didn’t know them until I used them without thinking about it, I didn’t know about M-RIGHT/C-RIGHT (right-word) and M-LEFT/C-LEFT (left-word), which do basically the same thing, but are a little bit more ergonomic since you’re not doing both keys with the same hand. Something to retrain, I suspect.

I probably also need to try to train myself to use my right Meta key more; unfortunately, on my laptop keyboard, it falls somewhat awkwardly under my thumb, so it may take some time to make that transition.

Finally (for today), there’s M-g M-g/M-g g (goto-line) which I use at least a couple of times a day…by typing M-x goto-line. I think this will be a little faster.

Welcome to ‘Do you even lisp?’

I was first exposed to the Emacs command set some time in 1990, while I was a sophomore in college; I owned an Atari ST, and stumbled across a port of Conroy’s uEmacs for TOS. It was a good little editor—capable and easy to use. In fact, as I was learning C at the time, I spent some time converting the source to ANSI C as an exercise.

I have used and even become pretty facile with a couple of other editors—I spent a lot of my last couple of years of college using Turbo Pascal, whose embedded editor used a command set derived from WordStar, and in my first job out of college I spent a lot of time writing Clipper code using Brief—but I’ve always had Emacs hovering in the background.

Then in 1994 I lucked into a job as a system administrator for a Unix system and even started using Linux as my primary desktop OS. The logical editor for me to start using was GNU Emacs, and I’ve never really looked back.

I use GNU Emacs a lot, every day—I read my email using Gnus, I track my to-do list and log my work time using Org-mode, I edit all my code and writing in Emacs—but in many ways, I feel like I’m still a raw beginner.

When I watch something like Magnar Sveen’s Emacs Rocks videos, I am constantly amazed at the fluidity with which he does things that would take me much longer because I’m not familiar with a lot of capabilities that he’s using. And the little snippets of elisp that he uses to simplify things in his What the .emacs.d!? posts blow me away with their ratio of bang for the buck.

In light of all this, I made a conscious decision to start actually studying GNU Emacs in 2013—and then I decided to chronicle my study, in the hopes that it might help others discover new things in GNU Emacs. When I remembered the Do you even Lift? meme, well, naming things is always the hardest but most important part.

So, the plan is for a post a day. The subjects will probably start out utterly mundane and basic—”Hey, did you know there’s a keystroke for that?” sort of stuff—but I hope that, over time, they may come to be more complex and sophisticated—less a chronicle of my own personal journey and more a contribution to the store of knowledge about ways to use Emacs most effectively.