scrolloff issue
viyic opened this issue · comments
commands that add a new line (like 'p' and 'o') right before scrolloff line can cause display issue.
before 'o':
after 'o':
this doesn't seem to happen in nvim-qt.
Can't really see what is the display issue here. Maybe you can make a video of it?
sure, this is me pressing 'o' a few times with scrolloff set to 3
Sorry, I really still can't see what is the problem. Do you mean its going down once? Are you sure its not the same in different neovim clients and with no config?
the problem in that gif is set linebreak "copies" itself and overwrites set showbreak and set breakindent, which presumably comes from Nvy not refreshing/re-rendering the lines when creating a new line with scrolloff enabled.
i have tried it in nvim-qt and it works just fine.
it still happens in Nvy even with no config (pay attention to set showbreak and set breakindent).
Oh, yeah sorry I did not know what kind of display issue I'm looking for :P
Well it seems fine for me. Any idea what I might be missing to reproduce it?
EDIT: actually its pretty obvious - it happens only with :nonumber set.
EDIT2: also it won't happen if you disable statusline with :laststatus=0
I think this may be fixed in #73 as I can't reproduce the issue - can you confirm that this is the case?
it still happens sadly.
i think the way to reproduce this is to :set nonumber, :set norelativenumber, :set laststatus=2, :set scrolloff=3, and try inserting new lines with o exactly above the scrolloff area without moving, so basically o<ESC>o<ESC>.
I'm trying to debug it but I am confused, I still can't figure out what's wrong. Initial guess was the right lines aren't being copied in renderer.cpp:ScrollRegion() but it seems to move the view down by one which seems correct so I don't think that's it. Why the lines aren't being updated with the proper content afterwards I do not understand. I'll try to find time to investigate more, in the mean time we could try to hotfix the issue by forcing a resize when inserting new lines, ugly but it would probably work.
I also tried to debug this but I wasn't able to find a problem with ScrollRegion either. At first I thought the bottom few lines just weren't being updated but they stay broken even if you continue editing and scrolling afterward. It's really strange... I'm not sure what other GUIs are doing differently in this case.
I've come back to this issue, and it seems that I found the bug. @viyic if you get the chance, please let me know if #90 fixes this for you. @RMichelsen it turns out ScrollRegion was only processing the first scroll event sent to it. The logic for shifting lines was correct, like you said.
Yep, works great, thanks!