Insert mode "eats" the line above cursor

[kyx0r]

Hello, entering insert mode using 'o' or 'i' and then hitting linefeed shifts every line and ends up not drawing the line above the cursor until you exit the insert mode. This is really annoying when editing and not something I would expect to happen. Let me know if this is an interesting issue to you as well. My terminal of choice is st, yet I have confirmed that this bug does not occur in tty nor xterm. The culprit is patch https://st.suckless.org/patches/anysize/st-anysize-0.8.1.diff which changes st window height to not be rounded to the equivalent rows * charheight, etc. Is there a way to patch out neatvi to be independent of this terminal size limitation? I'm thinking redraw stuff midway in insert mode may do the trick.

[kyx0r]

*Update never mind the anysize patch, it's actually caused by this patch :
https://st.suckless.org/patches/vim_browse/

[aligrudi]

Hello, Ether <notifications@github.com> wrote:

Hello, entering insert mode using 'o' or 'i' and then hitting linefeed shifts every line and ends up not drawing the line above the cursor until you exit the insert mode. This is really annoying when

Do you mean that you see two cursors on the screen? Ali

[kyx0r]

Hello Ali,

Here is how generally it works in unpatched st version and other terminals like xterm, tty, etc.
https://ibb.co/k8XDfht
On the image vi.c is open and cursor moved to line that says "WITH REGARD TO THIS SOFTWARE ..."
then 'o' is pressed. The bottom portion of the screen gets moved down and new line is created. This is just how it should
work, no issue here.

https://ibb.co/nwYd9VJ
This is how the same operation looks like in patched st build with vim_browse. You can see that the "WITH REGARD TO THIS SOFTWARE ..." was "eaten" and instead of bottom part shifting down, the top part moved up instead and now there is also a weird new line at line 0.

[kyx0r]

It feels like because vim_browse patch adds a history buffer that is "above" the current displayed characters, it also messes up the line where the '\n' should be created, meaning that '\n' is always inserted on line 0. So if you keep hitting linefeed (enter) the result will look like this: https://ibb.co/grZ3DVD

[aligrudi]

Ether <notifications@github.com> wrote:

It feels like because vim_browse patch adds a history buffer that is "above" the current displayed characters, it also messes up the line where the '\n' should be created, meaning that '\n' is always inserted on line 0. So if you keep hitting linefeed (enter) the result will look like this: https://ibb.co/grZ3DVD

OK. Please try the following in a st terminal when the screen is almost full: printf "\33[3H;\33[5L\n" it moves the cursor to the third line and inserts 5 blank lines. Does it work properly? Ali

[kyx0r]

It doesn't.

unpatched: https://ibb.co/5x17Pp4
patched:https://ibb.co/6WQ2LBg

[kyx0r]

Either way, I think the terminal is at fault here, I hope the patch maintainer from suckless sees this report here and fixes it, because terminal should not be changing the way basic commands like this work.

[aligrudi]

Ether <notifications@github.com> wrote:

Either way, I think the terminal is at fault here, I hope the patch maintainer from suckless sees this report here and fixes it, because terminal should not be changing the way basic commands like this work.

This seems to be the case and I hope it gets fixed. Ali

[kyx0r]

Fixed by maintainers.