Chris's Wiki :: blog/unix/EmacsForReadline

Why I think Emacs readline bindings work better than Vi ones

July 17, 2017

I recently saw a discussion about whether people used the Emacs bindings for readline editing or the Vi bindings (primarily in shells, although there are plenty of other places that use readline). The discussion made me realize that I actually had some opinions here, and that my view was that Emacs bindings are better.

(My personal background is that vim has been my primary editor for years now, but I use Emacs bindings in readline and can't imagine switching.)

The Emacs bindings for readline aren't better because Emacs bindings are better in general (I have no opinion on that for various reasons). Instead, they're better here because the nature of Emacs bindings make going back and forth between entering text and editing text, especially without errors. This is because Emacs bindings don't reuse normal characters. Vi gains a certain amount of its power and speed from reusing normal letters for editing commands (especially lower case letters, which are the easiest to type), while Emacs exiles all editing commands to special key sequences. Vi's choice is fine for large scale text editing, where you generally spend substantial blocks of time first entering text and then editing it, but it is not as great if you're constantly going back and forth over short periods of time, which is much more typical of how I do things in a single command line. The vi approach also opens you up to destructive errors if you forget that you're in editing mode. With Emacs bindings there is no such back and forth switching or confusion (well, mostly no such, as there are still times when plain letters are special or control and meta characters aren't).

Another way of putting this is that Emacs bindings at least feel like they're optimized for quickly making small edits, while vi ones feel more optimized for longer, larger-scale edits. Since typo-fixes and the like are most of what I do with command line editing, it falls into the 'small edits' camp where Emacs bindings shine.

Sidebar: Let's admit to the practical side too

Readline defaults to Emacs style bindings. If you only use a few readline programs on a few systems, it's probably no big deal to change the bindings (hopefully they all respect $HOME/.inputrc). But I'm a sysadmin, and I routinely use many systems (some of them not configured at all) as many users (me, root, and others). Trying to change all of those readline configurations is simply not feasible, plus some programs use alternate readline libraries that may not have switchable bindings.

In this overall environment, sticking with the default Emacs bindings is far easier and thus I may be justifying to myself why it 'makes sense' to do so. I do think that Emacs bindings make quick edits easier, but to really be sure of that I'd have to switch a frequently used part of my environment to vi bindings for long enough to give it a fair shake, and I haven't ever tried that.

As a related issue, my impression is that using Emacs bindings have become the default in basically anything that offers command line editing, even if they're not using readline at all and have reimplemented it from scratch. This provides its own momentum for sticking with Emacs bindings, since you're going to run into them sooner or later no matter how you set your shell et al.

Comments on this page:

By Aristotle Pagaltzis at 2017-07-17 05:13:15:

For me the problem that renders readline’s vi mode useless is that it doesn’t have any way of showing you what mode you’re in.

It’s a good point that small-scale edits are better done with modeless editing. I hadn’t even thought of that. The lack of mode indicator makes it so error-prone to use for me, I never got far enough to realise how irritating the mode-switching would be.

So most of the time the vi mode is inefficient, and when it’s not, it’s still unusable.

Fortunately, in bash, the whole issue is moot, because ^X ^E (edit-and-execute-command) takes care of the cases that require a stronger editor, and they’re rare enough that this solution is adequate.

By DrScriptt at 2017-07-17 12:15:55:

I agree with all of the above.

I wanted to point out that it is possible to support both Emacs and Vi keybindings at the same time. (At least in Zsh.)

A comment to Aristotle: I believe Zsh supports indicating Vi mode, insert vs command.

By Ewen McNeill at 2017-07-18 18:41:51:

I agree with your reasoning -- I too use vi/nvi/vim as my main editor, and have for a couple of decades, and use the Emacs keybindings for line editing, including as the shell command line editor, also for a couple of decades. As a consulting sysadmin/network admin I end up logging into a lot of other people's systems, often at a stage when they've only been partly configured, so adapting myself to the defaults definitely helps. Plus for trivial editing (such as a single command line) the Emacs keybindings are fairly quick to use and "being in insert mode" all the time helps with quick text entry.

I've also found over the years that the Emacs keybindings pop up in a lot of other places where they're the only option (eg, many switch and router CLIs, web browser URL bars, etc), so I'm pretty much inevitably using the Emacs keybindings anyway -- which makes "sticking with the default" on (bash) shell command line editing very much the most convenient option.

That said, I do find I use a very small fraction of the Emacs keybindings for command line editing -- pretty much the subset that I can be fairly sure is supported everywhere: ctrl-A/ctrl-E for start/end of line, ctrl-K for delete to end of line, ctrl-U for delete to start of line, ctrl-D to delete a character, and ctrl-T to transpose characters (plus ctrl-R for history search where I can). Between that and repetitive use of left/right arrow keys, and backspace, most manageable-sized command lines are relatively easily tweaked. Those ones work pretty much everywhere that supports Emacs-like keybindings for command line editing (except ctrl-D on Mikrotik which usually annoys me at least once on every login to a Mikrotik :-( )

By contrast when editing larger text in vi/vim/nvi I'll use a much larger subset of the editor's features to rapidly move around and/or make more substantial changes. With "larger than one line" text there's a lot of benefit gained from being in an "editing" mode that allows rapid movement/manipulation, separate from the insert mode. By contrast, with "one line" of text there's only so much movement and manipulation you need to do -- typically you're mostly just inserting a bit of text for the command and moving on to execute it, often without much editing beyond backspace. (I do find that while I normally use vim, I mostly use the vi -- or even ex -- subset of vim functionality. Again because it works everywhere. And because I first learnt vi before nvi or vim existed...)

Ewen

Written on 17 July 2017.

«	Why upstreams can't document their program's behavior for us

Link: NASA DASHlink - Real System Failures