[Bug]: Vi command mode '/' for search incorrect semantics

[John Cavanaugh]

What did you expect to happen?

When entering atuin via the '/' key in vi-command mode, the search field should be unset.

What happened?

Instead the search field is populated with the current command from bash.

Semantically that is incongruent to how bash search works outside of atuin. At least for bash this violates the least surprise principle.

I looked but didnt find any configuration to allow for this behavior.

Atuin doctor output

Version 18.2

Code of Conduct

• I agree to follow this project's Code of Conduct

[John Cavanaugh]

I should add that this is when atuin is configured in bash mode with disable up arrow.

[Koichi Murase]

This is not a bug but a matter of design. This was introduced by a request/suggestion by @Nemo157 at #1553 (comment), and it behaves in the current way intentionally. If @Nemo157 agrees, I think we can update the behavior of Bash and Zsh simultaneously (since I don't think it's a good idea to introduce inconsistency between Zsh and Bash).

Another thing to discuss is whether we should find another key in vi-command to start the Atuin search similar to C-r. / was chosen because one doesn't want to override C-r in vi-command. If users don't want / being the Atuin's C-r search, then we may need to pick another key for it.

I should add that this is when atuin is configured in bash mode with disable up arrow.

It's not "disable up arrow", but the option --disable-ctrl-r is relevant here. The / binding is a part of C-r bindings, so you need to pass --disable-ctrl-r instead of --disable-up-arrow to disable the / binding (or you can use export ATUIN_NOBIND=true). Then, you can manually set up your bindings following Key Binding.

[John Cavanaugh]

Thanks for the info. It makes sense there should be a way in vi-command mode to map to launching atuin. But I think there are 2 different modes that this should be launched. One mode will pass thru the current command line to atuin to begin the search, the other should not pass anything into atuin to begin the search.

I would suggest making these two use cases into functions that the user could configure what the key bindings are mapped to. For example, in my use case I would map '/' to the function that enters atuin with no passing of the command line, and I would map '?' to the function that enters atuin with the passing of the command line. Both of those are common search metaphors in vim and I think map nicely.

@Nemo157 what do you think??? Is this in keeping with atuin while making thigs as idiomatic for vim users??

[Nemo157]

I agree with this, I keep getting confused with / retaining the current text too.

[Koichi Murase]

Thank you both for the replies. Then, let's change the behavior. I'll take a look later.

[Nemo157]

To test it out locally I'm trying this out now:

_atuin_search_viins_clear() {
  BUFFER= _atuin_search_viins
}

zle -N atuin-search-viins-clear _atuin_search_viins_clear

bindkey -a / atuin-search-viins-clear

it's not quite right though, as it resets the cursor position if I cancel out