Multiline-buffer edit without search query

[vguerci]

To reproduce :

• call the widget until a multiline command appear (<UP>* x)
• then move to prepare to enter it / exit search mode (<LEFT>* x)
• move to enter in <UP>

Fails, we moved into next history entry instead of editing command.

This behavior only occurs when not using a search query. With a search query it behaves as expected.

[guidovansteen]

I agree with vguerci that the difference between using a search query and not using a search query is quite odd. Let us fix this.

[sorin-ionescu]

I can confirm this. It's quite annoying.

[guidovansteen]

Thanks a lot, sunaku and Sorin!

[vguerci]

thanks guys, also completely off/topic just noticed I was credited in the readme, again, thanks :)

[sorin-ionescu]

Just be aware that it behaves like Emacs mode, and if you have set vi mode, the arrow key bindings will be overridden.

The difference between up-line-or-history and vi-up-line-or-history is that the former will place the cursor at the end of the line while the later will place the cursor at the first non-white-space character at the begging of the line.

We could check for vi mode and use the vi widgets for those that prefer the vi behaviour. It should be configurable.

Personally, I do not like vi-[ up | down]-line-or-history because I tend to edit switches at the end of the line, not commands at the beginning of the line.

[guidovansteen]

We could make it configurable, although Fish always puts the cursor at the end of the line, like we do now.

At some places in our code we call CURSOR=${#BUFFER} to achieve this.

[sorin-ionescu]

CURSOR=${BUFFER[(i)[^[:space:]]]} should do it.

[guidovansteen]

Yes, it would place the cursor at the first non white-space character.

This might be a nice thing to have for vi mode addicts. I use vim quite often, but I do not use vi-mode under zsh. So I am not familiar with any other things that vi mode should do.