Documentation suggests "keymap_mode" exists but it's not in the config

[cohml]

The documentation states

keymap_mode

Default: “emacs”

The initial keymap mode of the interactive Atuin search (e.g. started by the keybindings in the shells). There are four supported values: "emacs", "vim-normal", "vim-insert", and "``auto". The keymap mode "emacs"` is the most basic one. In the keymap mode `"vim-normal"`, you may use k and j to navigate the history list as in Vim, whilst pressing i changes the keymap mode to `"vim-insert"`. In the keymap mode `"vim-insert"`, you can search for a string as in the keymap mode `"emacs"`, while pressing Esc switches the keymap mode to `"vim-normal"`. When set to `"auto"`, the initial keymap mode is automatically determined based on the shell’s keymap that triggered the Atuin search. `"auto"` is not supported by NuShell at present, where it will always trigger the Atuin search with the keymap mode `"emacs"`.

However, the config actually appears to expose no such parameter:

❯ atuin default-config | grep -q keymap_mode && echo found || echo not found
not found

This seems like a giant oversight, so it makes me wonder whether I'm missing something, or else whether the missing parameter is a known thing. But searching the current issues for keymap_mode and returns nothing, hence this issue feels justified.

[akinomyoga]

As far as I run the same command, it's in the config.

[murase@chatoyancy 0 atuin]$ atuin default-config | grep keymap_mode
# keymap_mode = "auto"

Which version of atuin are you using? The documentation reflects the configuration of the main branch. The config keymap_mode is a recently added configuration.

[ellie]

Yep, this is currently only on main and will be part of the next release

The documentation reflects the configuration of the main branch.

The documentation should probably be versioned, I'll add it to the todo

[cohml]

Then that would explain it, because I just installed atuin yesterday:

❯ atuin --version
atuin 17.2.1

I figured this was a known thing. However, the docs are also out of sync with the default value of enter_accept, yet the docs also explicitly acknowledge that. It was just weird why the enter_accept blurb had no such acknowledgement.

Anyway if this is already on the devs' radar, I will close the issue. Thanks for the lightening fast replies!

[ellie]

Thanks!

The docs for enter_accept are accurate

This technically defaults to true for new users, but false for existing. We have set enter_accept = true in the default config file. This is likely to change to be the default for everyone in a later release.

We prefill enter_accept as true for new users. If it is absent, it defaults to false

This means we wouldn't change the behaviour for existing users, as it's quite a big change

[cohml]

Sorry, I guess I was unclear.

I just meant that as I was skimming the docs yesterday top to bottom, for enter_accept the first thing I saw was

Default: false

This initially confused me, because it was inconsistent with my local default. But then I read further and saw that the docs already acknowledge this discrepancy. (Maybe you could put an asterisk there or something? "Default: false*". NBD 😄 )

By contrast, the discrepancy between docs and reality for keymap_mode is not similarly acknowledged. The docs say that parameter is there, but for people downloading the latest release it just....isn't.

But anyway, I see that it's coming, not an oversight. So we're in the clear 👍