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

14

Is there a longer-term intent to make the prefix override of Ctrl-A toggleable or customisable (ideally, that could land prior to the “configure all the bindings” ongoing feature plans)?

I’ve ended up in this thread after trying to figure out why the binding mysteriously stopped working recently, and turns out it was intentional (slight sidenote, the docs at Key Binding | Atuin Docs still mention the older bindings, not sure if it warrants an actual bug report?).

I like the prefix idea as a general solution to the limited keymap capability problem, my only quibble is that it’s one I use an awful lot! :slight_smile:

Having had a quick poke around in atuin/crates/atuin/src/command/client/search/interactive.rs at 88633b8994437180afdd66068cc2c8f02aea1db1 · atuinsh/atuin · GitHub, I think this is now causing Ctrl-a, d to (permanently?) delete the selected item from the history DB? If that is the case, I can see myself accidentally deleting random items when the muscle memory kicks in, which definitely doesn’t seem ideal.

15

I don’t think I understand. What muscle memory would be Ctrl-a d? This has never been used in atuin before.

The only thing that could be an issue is using tmux where the prefix has also been changed to Ctrl-a. (I am actually doing this.) But I have learned for many other utils that use ctrl-a as a prefix (or key combination) or for nested tmux sessions to use the proper escaping.

I believe that this prefix/key combination is perfectly fine for deleting a command. Peviously I had to open the inspector to do so. This is much easier to handle.

16

hey! welcome to the forum

It’s currently not configurable, but will be in the next release. I just merged

2 Likes
17

Sorry, looking back I wasn’t as clear as I was hoping.

My issue is that my muscle memory for “go to start of line, and add a missing D” (which I’ve come to expect to work in anything I’ve mentally categorised as “readline-ish”, which until recently included Atuin) is now bound to a destructive action, and from a quick experiment there doesn’t seem to be a huge amount of visual feedback or undo ability to indicate that you just deleted a history item.

GNU Screen uses Ctrl-A as a prefix key by default, which presents exactly the problem you’re describing, but as a default on a (probably still fairly popular?) utility likely to be in common usage with atuin.

The prefix/passthrough is (IMO) more of a workaround than a solution, since you now have to remember what prefixes are necessary in which situations, and internalise that so you don’t get it wrong.

18

Hey, thanks for the welcome, and also for such a speedy patch!

1 Like
19

You’re welcome! Hope everything else is working ok for you?

I’m not a fan of the prefix tbh, but given that matching readline is so difficult it came about as a reasonable alternative. If we’d used almost any other key, we’d run into similar issues with someone’s muscle memory somewhere, as readline uses them all

20

I’m actually fine with the idea of prefix keys, especially for less commonly used functions – there just aren’t enough distinguishable keys otherwise.

The “workaround” bit was about C-a, a being, in effect C-a (beginning-of-line). i.e. having the original function as an item in the prefix keymap, so its still accessible. It definitely can work, and is better than nothing at all so you can still reach that function, but can be pretty jarring for the slower-to-adapt amongst us :slight_smile:

My vote, insofar as I have one, would be for C-x as a prefix, since that’s where readline traditionally dumped all its rarely used functions. (Emacs reserves C-c as a specific user-customisable keymap, but that’s a bit too wacky given the much more common “cancel/send sigint” and/or “copy to clipboard” uses)

I’ve just built it locally and upon testing, I think to actually do what I want it’ll need to reinstate the original emacs keymap C-a binding

I think that’ll be fine because if the prefix-check will eat the keypress before it gets that far if its left at the default of C-a.

KeyCode::Char('a') if ctrl => self.search.input.start(),

(i.e.: revert the removal from the original prefix impl in b04fc471deb923937b8ef9aab2f39301f8457894)

I can have a stab at submitting as PR if that would be helpful?

21

Ok, this makes sense then.

Unfortunately this is not limited to atuin or shortcuts. This is something that you have to deal with in other situations as well. e.g. nesting, escaping, quoting, …

This can only be done if Ctrl-a is not used. Thus your PR needs to check that the prefix is not Ctrl-a.