Default key binding changes

General
1

Atuin currently has editing key bindings that are fairly similar to GNU Readline, which in turn is fairly similar to emacs

You can see a full list here: GNU Readline - Wikipedia

This is good for new users, as it ensures that their editing experience is consistent

However, it has made future features a bit trickier to implement. Looking through that list, most ctrl- bindings have been taken already for editing. Many of these bindings are equivalent to others. For example, ctrl-p → up arrow.

While I can appreciate the familiarity of an editing experience, I’d rather avoid making our own keybindings more complicated and emacs-y

I’d also love to be able to use ctrl-i to open an inspector for the currently selected command - but readline has that as another way to type “tab”.

Otherwise, ctrl-h for… help. But again, readline has that as another way to press backspace.

I’m very tempted to claim some of those for our own uses, but inevitably that will cause friction for some users. Other modifier keys lack consistent and reliable support - such as alt, super, cmd, etc.

In all likelihood, I’ll be breaking some of our readline parity in favour of more flexibility for development.

We do have an open issue for custom key bindings

but even when that is done, the defaults may feel a bit alien to some people.

Just creating this as a discussion to see if anyone has feedback or suggestions :blush:

One potential option is leaving as-is, but adding ctrl-shift-<char> to be our bindings, though these are not supported by all terminals

1 Like
2

Support for this sort of modifier combo: feat: enable enhanced keyboard mode by ellie · Pull Request #1505 · atuinsh/atuin · GitHub

Terminal support is limited, unfortunately

3

I think this is a real shame as there could be Alt- shortcuts for Atuin’s own use and Ctrl- shortcuts following the GNU Readline shortcuts.

I am not sure, however, how many people even know about them and use the GNU Readline shortcuts. I, personally, don’t even know they exist. And don’t plan on using them now that I heard about them. But I have no idea what the general knowledge about these shortcuts and their frequency of use is among Atuin users.

That being said, even if I found the GNU Readline shortcuts useful, I would personally be for primarily focussing on Atuin’s own shortcuts and using, for example, the ctrl-shift- versions for GNU Readline. They would be available on only some terminals, then, but at least the Atuin shortcuts would be available everywhere.

2 Likes
4

Ok perfect! I was thinking this might be the case. It seems like a low % of people even know about them in the first place

5

Especially when every other CLI application and terminal emulator breaks these rules, anyway, I presume.

It can be great for those who know and use them, so some support (with Ctrl-Shift-, for example) could still help those people, but I would personally not bend the desired design only to have a first-class support for GNU Readline shortcuts.

6

How about introducing a command mode à la vi?

1 Like
7

That could be a great solution, too. An advantage would be that the command modes could be easily extended with other modes for futher functionality. But is there (or will be) any new functionality that could use such command modes? The disadvantage is having to implement the whole command mode logic for possibly only one feature (GNU Readline-like shortcuts) that maybe not many people use.

Another problem with this approach in my opinion is that one would presumably want to use both Atuin’s own shortcuts and GNU Readline-like shortcuts interchangeably in quick successions, not use all the GNU Readline shortcuts, then switch the mode, and only then use all Atuin’s shortcuts, and possibly switch again. There would be way too much switching to shortcuts ratio, I think.

But maybe I am wrong. It is hard to say when I have never used the GNU Readline shortcuts myself. This is the impression I got from looking at the shortcuts for GNU Readline.

What do you think about these concerns? In addition, do you have an idea for something that could utilize the command modes except for the shortcuts for GNU Readline?

8

I’d love to! It can’t be the default though :confused: Much as I wish it to be the case, most people are unfamiliar with vi keybindings

Sure - mostly future functionality, but even things like deleting history, exploring history, switching search/filter/etc modes… It would make them more useful.

1 Like
9

Maybe this was already mentioned elsewhere, but the distinction between C-i vs tab and C-h vs backspace has a subtlety in the terminal’s support. There is the same issue with C-[ vs esc, C-m and return/enter.

First of all, the keyboard inputs return, tab, esc, and backspace are all encoded by corresponding control characters in the terminal-to-host stream historically. The keys modified by Control, C-<ascii>, are also encoded by corresponding control characters. This is the conventional rule shared by all the terminals. For this reason, they are indistinguishable within the standard keyboard protocol of the terminals. Also, this is not the area covered by termcap and terminfo.

Some of the terminals support extended keyboard protocols, such as XTerm’s modifiedOtherKeys and kitty’s keyboard protocol, so those keys may be distinguished in some terminals. However, not all the terminals support such an extended protocol. In particular, we can hardly expect the system consoles to introduce the support for an extended protocol.

This means that if we assign different functions to those pairs of keys, some of the Atuin features would be impossible to access from some environments. Or, it might cause an unexpected action in a system console. The shell experience would be a part of muscle memory for heavy users. Once one gets used to Atuin, one might not be able to live without Atuin. In such a case, the limitation to the environment can be frustrating.

Some of the extra modifiers (super s-, hyper H-, and even alt A- which is distinct from meta) seem to be suggested, but these are actually historical ones, which already disappeared effectively. We can find fewer terminals supporting them than the ones with the support for the extended keyboard protocols.

I’d suggest sticking with the keys available in the standard protocol for the default keybindings. I think we don’t have to strictly preserve all the Readline bindings, and we can also assign functions to key combinations. The keybindings do not need to be a single keypress.

1 Like
10

Thanks for clearing that up!

100%.

12

I think a prefix system like screen or tmux uses would be great. I was an avid screen user until tmux came around, which is why I changed the default meta in tmux from C-b to C-a :wink:

The number of possible shortcuts increases at least 3-fold.

13

Agreed on the prefixes. I wanted to avoid it originally, but I think it’s the least-bad option

I added initial support here

It uses ctrl-a.

I’ll add some config for that later