Entering vi insert mode eats one line above multi-line prompt

[burneyy]

Description

Using the vi key-bindings, the line above the multi-line prompt (e.g. pure) gets eaten up when entering from normal to insert mode.

Expected behavior

Entering insert mode should not change the lines above the current prompt.

Actual behavior

Entering the vi insert mode using any of the buttons "i", "I" or "R" removes the last line above the prompt and moves the prompt upwards.

In normal mode:

Entered insert mode by pressing "i":

However, it does not happen when entering insert mode by pressing "a" or "o".

Steps to Reproduce

1. In zpreztorc: Change from emacs to vi keybindings and select a multi-line prompt (e.g. pure)
2. Open a new terminal and enter a few commands so that the terminal fills up.
3. Go to vi normal mode by pressing ESC and change back to insert mode by either pressing "i", "I" or "R".
4. Note that the last line above the multi-line prompt got eaten up.

Versions

• Prezto commit: e6eea17
• ZSH version: 5.6.2, also tested with 5.3
• OS information: Mac OS Mojave, iTerm2

Possible Solution ?

I found in these lines that there is a special treatment for the functions "vi-insert", "vi-insert-bol" and "vi-replace" and that by commenting out the 3 function definitions, I can get the expected behaviour.
However, I unfortunately understand too less of these things to anticipate the consequences of commenting out these lines. I hope some of you can shed some light on it.

[johnpneumann]

I can confirm that this is an issue with the pure theme. However, on other multiline prompts that are internal to prezto (giddie, paradox, peepcode, steeef), the issue does not appear. This appears to have been introduced in fbcae35, which updated the pure prompt to the latest version (1.8.0 - sindresorhus/pure@5976e54).

In regards to commenting out those lines: It appears that this works, due to the fact that pure is handling vi insert modes and changing the prompt styling like is done for the sorin or paradox themes in 1.8.0. However, because it's doing this, it's incompatible with the way that prezto expects themes to function (namely by using the editor-info flags). I can confirm that this issue does not exist with the latest version of prezto (e6eea17) and version 1.7.0 (sindresorhus/pure@fa9137e) of the pure theme.

@indrajitr @belak - How do you want to handle this? Revert back to 1.7.0 until we can sort out what should be done?

[belak]

That sounds reasonable to me. Thanks for investigating!

[giorni]

Pure submodule was updated again (88456ec) and still don't work with vi bindings.

[johnpneumann]

@diraol @indrajitr @belak - should we lock the pure submodule to 1.7.0? I don't use pure and I'm not sure how we should continue to deal with this. Anyone have a relationship with pure or anyone in it? I don't love the idea of pinning it, but we also don't want to break everyone until we sort it out. Thoughts?

[belak]

My current preference would be to file an issue upstream and pin it with a link to that issue.

EDIT: I'm not 100% sure this is completely an issue with upstream - we do some weird nonsense with zle widgets and they might be conflicting.

[johnpneumann]

@belak - So I took some more time to look at this to see if it was something we're doing vs pure and the answer is, yes. The issue is that in the commit I referenced above (sindresorhus/pure@5976e54) pure is now doing a rest of the prompt the same as we are when using vi keybindings. This conflicts with the way that the editor module handles keybindings for vim as well. What pure introduced is basically the same thing that we've had with the editor:info:keymap bits that are set in the prompts. Specifically its to provide what prezto calls the "alternate" format, which shows when you're no longer in insert mode.

I am looking at ways to mitigate this, but I'm afraid that the change in pure is a breaking change that will continue to be an issue when upgrading.

Before I file an upstream issue, I'd like to have an idea of how we can have things coexist without either of us having to do nasty things (like us checking if it's the pure prompt or pure checking if it's being used in prezto).

I'll explore some more options, but the "easiest" option I can think of is to split the editor module off into its own repo and try to get that implementation to be the standard for prompts moving forward. It would allow other modules to state that folks would need that module as well, and then we could alleviate issues like this (with pure or spaceship or whatever prompt it is). If a consensus can be reached on how things should be implemented for prompts (think css but for zsh), then maybe that'd create consistency.

The long explanation probably sums up why "easiest" is in quotes. I'll see what else I can come up with.

[belak]

@johnpneumann Did you get a chance to look in to this?

[johnpneumann]

I did and the net-net is someone has to add a check into their code to ensure that the update doesn't happen twice. Splitting the editor module out (while it might be nice), would mean that we'd need to find a new home for it and we'd be taking some fairly core functionality to address the issue at hand.

My preference would be that the check come from the theme side ONLY because we're a framework. If we add in one for this, we'll have to support multiple eventually and that sounds tedious and prone to breaking things long term. Thoughts?

[belak]

Thanks for looking into that. There's so much interacting here, it's hard to follow sometimes.

Could we provide a convenience function that a prompt could call in its setup function to enable the built-in reset? Along with a way to disable it on unload. Then we could still include the functionality in our themes, but it wouldn't interfere with external themes.

[johnpneumann]

@belak - Never responded, but I'm still looking at the best way of handling this. Yes, we can do what you're suggesting, but what I'm finding right now is that even when we disable any of the updating of the reset, pure 1.8.x and up eats the line above it. It's actually really irritating me right now, because I've tested this on 3 separate OS' (Arch [release: 2018-11-05; zsh version: 5.7.1], Debian Buster [zsh version: 5.7.1], and Mojave [release: 10.14.5; zsh version: 5.7.1]) and it exists on every OS. I even put the conditional around the entire editor-info block and it still occurs.

I'm hoping this isn't another 5.3.1 debacle, so I'm going to build 5.4.2 on a few systems to see if I can repro with that version, since that was the last version I can remember working fine. What's actually disconcerting about this, is that if you use one of the prompts we provide, it works just fine on all of the aforementioned OS'. I may try this with ohmyzsh to see what happens there as well.

[johnpneumann]

So here's where things are at: I've tested on 5.7.1 across multiple nix distros and MacOS. I also tested on 5.4.2. With everything being a conditional for the aforementioned functionality it works... Ish. It appears that there's a bug within the pure prompt, that when you go quickly from command mode to insert mode, you'll consume the previous line. I tested this with prezto, as well as, just with the pure prompt with nothing else.

So, I'll add in some hooks to disable the prompt management by the editor for non-prezto managed themes, but there will still be an upstream issue. Should have it wrapped up in a day or two (want to make sure we don't break our prompts in the process).

[johnpneumann]

PR opened to fix the issue. Anyone affected with this, please check the proposed changes. It's 2 lines (if you omit the readme update and the fact that I indented things).

You'll need to git checkout master in the pure directory as well and switch your prompt. I'm working on getting my test environment for Prezto open sourced, but $dayjob rules.

Also, please note my above comment that pure is still broken when quickly changing from command to insert mode.