Vi-mode doesn't play well with multi-line prompts

[paradox460]

I have a multi-line prompt, where there is information displayed on one line, and the user input goes on the second. Basically handled through something like this:

echo -n -e -s (pwd) (__fish_git_prompt)"\n$"

This has worked without flaw in vi-mode in the past. As of version 2.3.1-667-g668de88, and likely caused by #3215, switching modes results in the whole prompt being pushed down, not redrawn over the existing prompt.

<insert mode:>
[ i ] ~/developer/docker
$ docker-compose start api

<switching to normal mode>
[ i ] ~/developer/docker
[ n ] ~/developer/docker
$ docker compose start api

Additionally, the cursor does not redraw as a bar/underscore, but remains how its configured

System info

• fish, version 2.3.1-667-g668de88
• OS X 10.11.6
• iTerm Build 3.0.11
• Theme: https://github.com/paradox460/paradox-theme
• Dotfiles/fish config: https://github.com/paradox460/.dotfiles/tree/master/.config/fish

This issue is new, and cannot be reproduced in the stable (2.3.1) version of fish

[faho]

What happens if you save an empty fish_vi_cursor function, i.e. add the following to config.fish:

function fish_vi_cursor; end

?

[faho]

I cannot confirm this with konsole (which uses the same cursor sequences).

[paradox460]

Adding function fish_vi_cursor; end to my config fixes the redrawing issue. Calling echo -en '\e]50;CursorShape=1\x7' manually, however, does change the cursor shape.

Here's what the envars referenced in fish_vi_cursor are set to on my machine:

TERM=xterm-256color
ITERM_PROFILE=Default

[paradox460]

Additionally, overloading __fish_cursor_konsole and __fish_cursor_xterm with an echo statement specific to each one shows that __fish_cursor_konsole is being called.

[faho]

What are your $fish_cursor variables set to? Specifically $fish_cursor_insert and $fish_cursor_default?

[paradox460]

Only unknown appears to be set

$ set | grep cursor
fish_cursor_unknown 'block'  'blink'

[faho]

What happens when you set them? Is there any difference between "block" and "line" and "underscore"? (Any other value should disable this function)

[paradox460]

Setting them makes the cursor change work, but the newline bug is still there.

I've noticed a few behaviors of the newline bug:

• it only occurs when transitioning from insert to normal mode
• transitioning from normal to insert or visual, or from visual to normal, behaves as expected
• transitioning when the cursor is at the start of the line in insert mode behaves as expected. the bug is only reproducible if the cursor is anywhere else in the line, including the end

[faho]

it only occurs when transitioning from insert to normal mode

That's good to know. The escape binding in insert mode is a bit complicated to allow canceling in the pager and to facilitate vi's weird behavior of moving the cursor back.

Can you try bind -M insert -m default \e cancel or "force-repaint" instead of cancel?

[paradox460]

Force repaint fixes the issue for transitioning the cursor at its current position between modes, but in testing it I found another oddity: whenever I use operations that both move the cursor and change normal to insert (eg: I, A) the bug is reproduced. This applies even with force-repaint in play

[faho]

Force repaint fixes the issue for transitioning the cursor at its current position between modes

If you mean that the cursor moves back when you enter normal mode, that's on purpose, because that's what vi does.

whenever I use operations that both move the cursor and change normal to insert (eg: I, A) the bug is reproduced. This applies even with force-repaint in play

My guess is iTerm doesn't handle that particular sequence of escape sequences correctly.

Can you record a session with script (ie. execute script, reproduce the problem and then exit, this will create a file called typescript which you should upload somewhere - I'm not sure if github's comment system will mangle it)?

Can you try it with an empty fish_mode_prompt function?

[paradox460]

I meant bind -M insert -m default \e force-repaint works as I believe it should; as it used to before this bug cropped up.

I've attached the typescript in a zip so as to prevent github from messing it up
typescript.zip

[zanchey]

@paradox460, from my reading it doesn't look like this affects 2.4b1 - are you able to test that version?