Irreal

Over at The MKat, Marie K. Ekeberg has a post that brings me back to my earliest days of using Emacs. Before I was assimilated, I tried several times to warm up to Emacs but it wouldn’t take. Ekeberg’s post reminds me why. It was what I considered the schizophrenic default scrolling. You would move the cursor down the screen and suddenly, about three quarters of the way down, the screen would jump several lines. Every time I saw that, I would abandon my attempt to embrace Emacs and run screaming back to Vim.

In her post on smoother scrolling, Ekeberg offers an explanation for this bizarre behavior that I’m pretty sure is correct. The TL;DR is that in the old days, when Emacs was developed, scrolling was an expensive operation so rather than scroll by line, Emacs would scroll by (essentially) half pages.

I have no idea why the default hasn’t long since been changed but as far as I know, it hasn’t. I say, “as far as I know” because years and years ago I did what Ekeberg suggests and implemented smooth scrolling. I haven’t looked back.

It turns out that fixing this is far from trivial. I have no memory of how I figured it out but I do know that it involved pleading with the Internet for an answer. Take a look at Ekeberg’s post to see the answer. What she suggests is essentially what I did. As I said, not at all obvious.

It’s odd how a simple thing like scrolling can ruin your appreciation of Emacs but it sure did affect mine. Don’t let that happen to you. Take a look at Ekeberg’s post and find peace of mind.

Back in the bad old days when personal computers weren’t nearly as reliable as they are today, it was common to have your computer crash when you were right in the middle of writing a document. Because of that, a common mantra was, “save early and often”. That way, when the crash came you would have only a few lines to rewrite.

I first heard the particular expression “save early and often” from Jerry Pournelle but it may not have originated with him. It was common advice back then but the humorous twist does seem like Pournelle, so who knows. In any event, in those days it wasn’t just good advice, it was mandatory.

I was reminded of all this the other day when I was writing yesterday’s post on the latency of computer operations. I was switching back and forth between the post’s Emacs buffer and Ahmad’s post in Safari, when Safari suddenly froze and I couldn’t find a way to break out of it and get back to Emacs to save my buffer, which, sadly, I hadn’t bothered to backup as I went along. In the end, I had to reboot the machine to get things back to normal.

Of course my whole post was gone when my laptop came back up. Note that this was not Emacs’ fault. It was Safari that froze and it was me that didn’t bother saving my work. Actually, Emacs was the hero in all this because the autosave function rescued me from my folly. I hardly ever need to use it so I always have a hard time remembering what to do but in the end I got almost my whole post back.

The takeaway from all this is that even with reliable hardware and software, crashes and freezes can still happen so if you care about your work make sure to back it up often. Or, as Pournelle would have it, early and often. If you don’t, the day will come when even Emacs can’t save you.

Over at the Emacs subreddit, weevyl talks about how Emacs completion changed his life. Or at least his Emacs life. His story is about his repeated efforts to move to Emacs and always failing. He finally realized that the reason for his failures was the difficulty of learning and remembering command names. We’ve all been there. You load a new package and suddenly you have some new commands to remember.

Weevyl’s epiphany was that command completion can virtually eliminate this problem. He’s a Helm user but the same principals apply to Ivy and other such packages. When you start to type a command name, you get a list of completions to help you choose the right one. I’m not a Helm user but with Ivy, the search is fuzzy and it’s often enough to start with the package name to get a list of available commands.

I use this all the time and have long since stopped thinking about it but weevyl’s post made me realize what a powerful facility this completion is. You don’t have to try to remember a long list of commands or their bindings. As I said, it’s usually enough to remember the package name to get a list of commands that make it easy to narrow down to the desired target.

There’s lots of agreement in the comments. Several people have almost the same story. Others have written some Elisp to help with this and shared their code so if you’re also finding remembering Emacs command names daunting, take a look at the post. It’s easy to forget how much Emacs does—or can do—to make our workflow easier.

Over that the Emacs reddit, arni_ca asks about key bindings for cursor movement. It’s not quite clear what he’s asking but the theme is moving the cursor without bindings like Ctrl+f, Ctrl+b,
Meta+f,
Meta+b,
Ctrl+n, and Ctrl+p.

As is often the case, all the juice is in the comments. It’s astounding how many different strategies people have for such movements. They range from everything to using the arrow keys to custom Elisp snippets. Take a look at the post to see if any of the ideas will work for you.

By now, you all know my answer to questions like this. I started with this epiphany from Steve Yegge: large scale navigation—more than a few characters or lines—should be made with search. It’s perfectly obvious but it occurs to few of us until someone points it out. The wonderful avy package refines this strategy and offers finer grained control of where the cursor ends up. Avy is probably my most used set of commands. I use them constantly as I write and edit. Following Karthinks, I’ve mostly pared my use down to avy-goto-char-timer although I do sometimes still use avy-goto-word-1. Regardless, if you aren’t already using Avy, you should take a look. It’s the backbone of my navigation.

The other navigation tool I use is an import from Vim: jump-char that lets you jump to the next or previous instance of a character. It’s incredibly useful and, again, I use it several times a day. If you use Avy and Jump-char, you will have most of your navigation needs met.

I’ve written before about relative line numbers. The idea is to label the current line as 0 and the other lines as positive or negative offsets from it. It’s handy if you want to quickly move to another line. As I said before, there are ways—avy in my case—that you might find better for doing that kind of thing.

In another of his useful posts, Bozhidar Batsov gives his own take on relative line numbers. Batsov says that relative line numbers are particularly useful if you are an evil user but even users of conventional Emacs can find it useful. If this sort of thing interests you, take a look at Batsov’s post for some details.

As I said in my previous post on the matter, I’ve never been able to warm up to the idea. I seldom have line numbers enabled but when I do I find it just as easy to jump to an absolute line number. Actually, I don’t do that either, I just use avy to get where I want to go. It generally provides finer control over where the cursor lands and is just as easy to use.

Of course, as I always say, that’s the beauty of Emacs. You can adapt it to whatever your preferred workflow is. If relative line numbers seem like a good idea to you, take a look at Batsov’s post.

The other day, in response to my The Power Of Elfeed post, René Trappel wrote to me offline about his Elfeed package that enables content search. He calls his package “Cuckoo Search” for reasons you can discover at his Github repository.

By default, Elfeed doesn’t search the content of a post, just the metadata such as title, date, and tags. With Trappel’s package you can do finer searches. If you often want to do fine grained searches for posts that previously appeared in your feed, take a look at Trappel’s package.

I’ve always found the default search adequate but it’s easy to imagine needing the additional capability offered by Cuckoo Search. The package is not yet available in ELPA but Trappel gives a recipe for installing it directly from his Github repository. I’ll probably wait until it appears on ELPA to install it unless I find myself needing its capability in the mean time.

For a very long time I’ve been using swiper-isearch in place of the default isearch because I like the way it lists the results in the minibuffer, lets you scroll through them, and pick the result you want On the downside, it’s not always clear which target you’re looking at when you have long lines, which I often do because I write with visual-line-mode enabled, but I’ve stuck with it out of habit.

Now Bozhidar Batsov has come along to blow up my comfortable status quo. It turns out that isearch is way more powerful than most of us knew. It’s not a secret. All this “hidden” power is described right there in the docstring. It’s incredible that it’s not better known.

There are a bunch of commands to add or delete characters or words to or from the search string, often from whatever happens to be at point. There are also several toggles such as case sensitivity, whether or not to search for invisible text, regular expression mode, and others.

Finally, you can edit the search string in the minibuffer, scroll through a history of the last 16 search strings, and, as mbork told us the other day, you can search for the symbol at point. There’s more so take a look at Batsov’s post or the docstring. As Batsov reminds us, you can see all the options when you’re already in isearch by typing Ctrl+h b.

This is a really useful post and has me thinking that maybe I should return to isearch. Of course, I can have both; the real question is what should be bound to Ctrl+s.