After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 742767 - vim: scrolloff setting greater than 1 allows scrolling from top to bottom
vim: scrolloff setting greater than 1 allows scrolling from top to bottom
Status: RESOLVED FIXED
Product: gnome-builder
Classification: Other
Component: editor
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GNOME Builder Maintainers
GNOME Builder Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-01-11 17:24 UTC by Florian Bäuerle
Modified: 2015-01-13 10:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
fix (1.15 KB, patch)
2015-01-11 17:44 UTC, Florian Bäuerle
committed Details | Review
source-vim: Dont go to negative lines when adjusting scroll (1.41 KB, patch)
2015-01-13 09:52 UTC, Carlos Soriano
committed Details | Review

Description Florian Bäuerle 2015-01-11 17:24:20 UTC
Just try to navigate to the very top of the document with PgUp while having a scrolloff value greater than 1. You will end up at the bottom of the document if you press PgUp "too often".
Comment 1 Florian Bäuerle 2015-01-11 17:44:46 UTC
Created attachment 294292 [details] [review]
fix

Maybe this should rather be handled inside gb_source_vim_adjust_scroll, since this function handles lines exceeding the number of lines in the current document properly.
Comment 2 Christian Hergert 2015-01-12 00:20:11 UTC
I don't think this fixes the bug for me, but maybe I'm looking at the wrong thing?

The cursor still jumps to the bottom occasionally. I would expect things to stay in the same y position, right?
Comment 3 Florian Bäuerle 2015-01-12 20:22:22 UTC
Ok, try this without the patch applied (with scrolloff=4 for example):

1. open i.e. vim/gb-source-vim.c
2. put the cursor to the very first line (with cursor keys)
3. press PageUp

expected result: Cursor stays at this position in the first line
reality: Cursor resides in the last line of the document
Comment 4 Christian Hergert 2015-01-12 23:39:19 UTC
Well that certainly does fix your stated problem. I think we have some other issues we need to fix as well, but that can be a separate bug.
Comment 5 Carlos Soriano 2015-01-13 09:48:41 UTC
The error is not here. The line at that point is 0, so it's correct. Also that solution is wrong, put a scrolloff of 999 and pageUp, you end at line 999.

The problem is adjusting the yalign in adjust_scroll, since it ends in -scrolloff.
Easy to fix with making sure not adjusting to less than line 0.
Comment 6 Carlos Soriano 2015-01-13 09:52:35 UTC
Created attachment 294408 [details] [review]
source-vim: Dont go to negative lines when adjusting scroll

Commit  fbb1252c tried to fix that, but the error was not there.
Comment 7 Carlos Soriano 2015-01-13 09:54:26 UTC
(In reply to comment #4)
> Well that certainly does fix your stated problem. I think we have some other
> issues we need to fix as well, but that can be a separate bug.

I will be happy to take a look on them =)
Comment 8 Christian Hergert 2015-01-13 09:56:23 UTC
Looks good

Attachment 294408 [details] pushed as 2d19ace - source-vim: Dont go to negative lines when adjusting scroll
Comment 9 Christian Hergert 2015-01-13 10:08:36 UTC
(In reply to comment #7)
> (In reply to comment #4)
> > Well that certainly does fix your stated problem. I think we have some other
> > issues we need to fix as well, but that can be a separate bug.
> 
> I will be happy to take a look on them =)

I thought it was off with regards to ctrl+f/ctrl+b and pageup/pagedown, but after comparing to vim, it looks pretty close.

Where we do ctrl+e/ctrl+y support is a problem, since it isn't taking this into account. So we might need to figure something out there (possibly by putting a bindingset into gbsourceview and some conditional code in gbsourcevim).

Another thing, that I find annoying, and unrelated to your work (it happens all over the place), is that when we move lines quickly it looks like the highlight line jumps around. I don't have any suggestions for fixing this without some major work in gtksourceview.