hmmm... i think that might be a nushell bug. I think nushell should be overriding global keybinds like "up arrow" with local keybinds but isn't doing that.

Have you opened an issue in the nushell repo? if so, can you link to it here?

This issue leads to a pretty terrible experience, should we disable the up arrow by default for Nushell until this can be fixed?

This issue leads to a pretty terrible experience, should we disable the up arrow by default for Nushell until this can be fixed?

I think that would probably be best, though hopefully their keybindings become more flexible soon 🙏 Are you happy to make the PR?

FYI the default keybinding in nu is this

    {
        name: move_up
        modifier: none
        keycode: up
        mode: [emacs, vi_normal, vi_insert]
        event: {
            until: [
                {send: historyhintcomplete }
                {send: menuup}
                {send: up}
            ]
        }
    }

I think the "until" is how you leverage "doing the right thing at the right time". I don't know any more details than that.

I'm not sure where you copied this from, but the default config seems to be this and hasn't changed in a while, except for formatting:

        {
            name: move_up
            modifier: none
            keycode: up
            mode: [emacs, vi_normal, vi_insert]
            event: {
                until: [
                    {send: menuup}
                    {send: up}
                ]
            }
        }

You can find the until reference here: https://www.nushell.sh/book/line_editor.html#until-type

Based on this, I modified the commented out part in the init script

$env.config = (
    $env.config | upsert keybindings (
        $env.config.keybindings
        | append {
            name: atuin
            modifier: none
            keycode: up
            mode: [emacs, vi_normal, vi_insert]
            event: {
                until: [
                    {send: menuup}
                    {send: executehostcommand cmd: (_atuin_search_cmd '--shell-up-key-binding') }
                ]
            }
        }
    )
)

This seems to work! I can navigate through menus and when not in one I'm opening atuin.
Maybe I'm missing something but I think this is the fix.

Basically it first tries to do the menuup action, if that fails (because we're not in a menu), it tries atuin.

I was thinking to add a {send: up} fallback at the end when atuin fails, but the docs make it sound like currently only the menu actions can fail in a way that makes the next "until" item fire.

And yeah, when I modify the command to produce a positive exit code, the current behaviour seems to be that it just silently stops or crashes in some way, and nu gives me a new line. Instead of going to the next action in the array (what I thought might happen).

Awesome - I went ahead and created a PR before I forget - let me know if the fix works for you!

Oh, and just for the next person being confused, the original issue description is probably meant to say Type "math" and press tab. since the default tab-autocompletion opens as a menu with options.

At least that is how I could reproduce the behaviour in menus.

Even though this PR is merged the init file has commented code for the binding with a link to this PR. Is that expected?

# The up arrow keybinding has surprising behavior in Nu, and is disabled by default.
# See https://github.com/atuinsh/atuin/issues/1025 for details

@msminhas93 The text should indeed not be generated anymore, no. Make sure that you have version 18.1.0 installed (or a newer commit).

Since the fix is part of what the init script outputs, you will not get the new version of the init file unless you manually recreate it after updating to the latest version. Note that this will overwrite manual changes you might have made to the init file.

As per the script in the Readme, assuming you haven't changed the paths:

atuin init nu | save -f ~/.local/share/atuin/init.nu

Thanks that was it!