Command z<CR> doesn't work

[Cesar Romani]

I'm using vim 80.069 on Windows with defaults.vim enabled.

When pressing z<CR>, the cursor line is supposed to get to top of
window, but is placed 5 lines below the top.

Many thanks in advance,

--
Cesar

[Christian Brabandt]

Hi Cesar!

On Di, 08 Nov 2016, Cesar Romani wrote:

> I'm using vim 80.069 on Windows with defaults.vim enabled.
>
> When pressing z<CR>, the cursor line is supposed to get to top of
> window, but is placed 5 lines below the top.

:h 'scrolloff'

Best,
Christian
--
Stilblüten aus Schreiben von Versicherungsnehmern:
Als ich an die Kreuzung kam, erhob sich ein Zaun, um meine freie Sicht
zu hindern.

[Ben Fritz]

On Tuesday, November 8, 2016 at 11:51:05 AM UTC-6, andalou wrote:
> I'm using vim 80.069 on Windows with defaults.vim enabled.
>
> When pressing z<CR>, the cursor line is supposed to get to top of
> window, but is placed 5 lines below the top.
>

This is due to the 'scrolloff' option which defaults.vim sets, you will need to override it with a plugin or VimEnter command, or avoid sourcing defaults.vim, if you don't like the behavior.

'scrolloff' is useful for always keeping some lines of context above/below your cursor at the window edges.

[Cesar Romani]

Thanks Christian and Ben. So z<CR> depends on scrolloff. I think, this
should be indicated on :help z.

Best regards,

--
Cesar

[lylez]

Folks, this is a classic example of a bug masquerading as a feature. Not only does the z-<CR> functionality not work, but I can't even move the cursor above the fifth line being displayed by pressing the k key, unless the file is scrolled all the way to the top.

This is like if a car company sold a car that, every few hundred miles, suddenly lurched hard left, causing it to collide at high speed with oncoming traffic. When alerted to this, the car company responds by saying, "Oh yeah, that's the default behavior, but not to worry, all you have to do is press the stereo volume button, AC button, and radio station tuner buttons, all at the same time, and then turn the station to 99.0 FM, and the problem will be gone".

It wasn't like this in Vim 7.4, but it is in Vim 8. Please fix.

Regards

Lyle

[Ethan Hereth]

Lyle,

Did you miss the posts earlier about the 'scrolloff' option? :help scrolloff explains this option. Do you have a custom .vimrc file? :help defaults.vim (mentioned at :help scrolloff) says that if you do not have a user .vimrc, defaults.vim will be sourced and it will set the scrolloff option to 5 which explains what you are seeing. This is not a bug.

Cheers,

Ethan Alan

 

Regards

Lyle

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[lylez]

Yes,I did see that, but I respectfully maintain that basic functionality should not depend upon .vimrc entries.

[Bryan Richter]

On Sat, Nov 12, 2016 at 01:22:31PM -0800, lylez wrote:
> On Tuesday, November 8, 2016 at 9:51:05 AM UTC-8, andalou wrote:
>
> > I'm using vim 80.069 on Windows with defaults.vim enabled.
> >
> > When pressing z<CR>, the cursor line is supposed to get to top of
> > window, but is placed 5 lines below the top.
> >
> > Many thanks in advance,
> >
> > -- Cesar
>
> Folks, this is a classic example of a bug masquerading as a
> feature. Not only does the z-<CR> functionality not work, but I can't
> even move the cursor above the fifth line being displayed by pressing
> the k key, unless the file is scrolled all the way to the top.

To respectfully offer the counter position, this is a feature that
ensures the cursor line is surrounded by lines of context whenever
possible.

What has changed between vim 7 and 8 is that the maintainers have
switched from one point of view to the other.

I don't see any way to reconcile the two points of view other than to
provide an option to allow either position. Thankfully, that is already
done.

[Cesar Romani]

What do you read if you do ':help z'?
You get:

--------------------
|z<CR>| z<CR> redraw, cursor line to top of window,
cursor on first non-blank
--------------------

Where is top of window?
Is it five lines after the top?

--
Cesar

[Bryan Richter]

On Mon, Nov 14, 2016 at 01:38:11PM -0500, Cesar Romani wrote:
> On 14/11/2016 12:56 p.m., Bryan Richter wrote:
>
> > On Sat, Nov 12, 2016 at 01:22:31PM -0800, lylez wrote:
> >
> >> On Tuesday, November 8, 2016 at 9:51:05 AM UTC-8, andalou wrote:
> >>
> >>> I'm using vim 80.069 on Windows with defaults.vim enabled.
> >>>
> >>> When pressing z<CR>, the cursor line is supposed to get to top of
> >>> window, but is placed 5 lines below the top.
> >>>

> >> Folks, this is a classic example of a bug masquerading as a
> >> feature. Not only does the z-<CR> functionality not work, but I
> >> can't even move the cursor above the fifth line being displayed by
> >> pressing the k key, unless the file is scrolled all the way to the
> >> top.
> >
> > To respectfully offer the counter position, this is a feature that
> > ensures the cursor line is surrounded by lines of context whenever
> > possible.
> >
> > What has changed between vim 7 and 8 is that the maintainers have
> > switched from one point of view to the other.
> >
> > I don't see any way to reconcile the two points of view other than
> > to provide an option to allow either position. Thankfully, that is
> > already done.
> >
>
> What do you read if you do ':help z'?
> You get:
>
> --------------------
> |z<CR>| z<CR> redraw, cursor line to top of window,
> cursor on first non-blank
> --------------------
>
> Where is top of window?
> Is it five lines after the top?

Aha, now I can agree there is room for improvement. The docs should be
updated to mention that z<CR> is impacted by 'scrolloff'.

That probably should have happened a long time ago, in fact.

I would submit a patch, but I'm not set up to be a vim contributor, and
I don't have the time to do so right now. Maybe someone else?

P.S. I don't use 'scrolloff', so I do not know if there is any other
general solution to the mutually incompatible goals of z<CR> and
'scrolloff'.

[Gary Johnson]

On 2016-11-14, Bryan Richter wrote:

> Aha, now I can agree there is room for improvement. The docs should be
> updated to mention that z<CR> is impacted by 'scrolloff'.
>
> That probably should have happened a long time ago, in fact.
>
> I would submit a patch, but I'm not set up to be a vim contributor, and
> I don't have the time to do so right now. Maybe someone else?
>
> P.S. I don't use 'scrolloff', so I do not know if there is any other
> general solution to the mutually incompatible goals of z<CR> and
> 'scrolloff'.

I don't use 'scrolloff' either. I tried it for a short while and
not being able to put the cursor in the offset region when I wanted
to drove me crazy.

However, I do like having some context when jumping. For example,
when I'm searching for a pattern and I hit 'n' and the cursor jumps
to the bottom of the window, I like having some idea of the context
of that line, i.e., what are the following few lines. So I now have
mappings for n, N and a few other keys so that when jumping around
in a file using those keys, I always have at least two lines of
context around the matched line.

Here is the function and some of the mappings that use it, in case
anyone is interested.

" Leave a little space at the top or bottom of the screen for context when
" executing 'n' or 'N'.
"
nnoremap <silent> n nzv:call AdjCursor()<CR>
nnoremap <silent> N Nzv:call AdjCursor()<CR>
function! AdjCursor()
let l:wh = winheight(0)
if l:wh <= 2
return
elseif l:wh <= 4
let l:vmargin = 1
else
let l:vmargin = 2
endif

" The algorithm at the bottom of this function has a problem when the
" match is found on a really long line that wraps many times in the
" display. I don't know what the correct solution is, so for now we'll
" just bail if the line wraps.
"
if virtcol("$") > &columns
return
endif

" When positive, l:scrollup is the number of lines that need to be
" scrolled up to leave l:vmargin lines between the cursor and the top of
" the window. Similarly, when positive, l:scrolldown is the number of
" lines that need to be scrolled down to leave l:vmargin lines between the
" cursor and the bottom of the window.

let l:scrollup = (l:vmargin + 1) - winline()
let l:scrolldown = winline() - (l:wh - l:vmargin)
if l:scrolldown > 0
exe "normal ".l:scrolldown."\<C-E>"
elseif l:scrollup > 0
" Scrolling will have no effect when the first line of the buffer is
" at the top of the window, but it doesn't cause an error, either, so
" we won't test for that condition.
exe "normal ".l:scrollup."\<C-Y>"
endif
endfunction

It doesn't address all the cases I'd like it to, such as after an
initial search with '/' or '?', and it has the side-effect of
clearing the "search hit BOTTOM, continuing at TOP" message, but it
addresses the behaviors that annoy me most. It would be nice if
this behavior could be made part of Vim, say as a 'jumpoff' option,
but I'm not in a good position to code that, at least not at the
moment.

Regards,
Gary

[Eric Calvayrac]

I discovered 'scrolloff' not long ago and liked it. But I was also bothered by the z<CR> behavior.

Since I wanted the line to be really on top of window, but didn't mind if the cursor move, I use the following mapping:

:nnoremap z<CR> :exec line('.')+&scrolloff<CR>z<CR>

Works fine for me, although it doesn't work for the last lines of the buffer.

Regards,
Eric

[lylez]

If this functionality is desired, fine, but it should be turned off by default with an option to turn it in, instead of the other way around.

Imagine you're on an unfamiliar machine working a time-critical production problem, and you don't have time to fiddle around with the .vimrc file (and likely shouldn't be doing so anyway because it's not your machine). This would drive a person nuts. I honestly can't see any reason why it should be this way. I stand by my earlier comment in which I compared this bug with a car suddenly lurching hard left every so often (see above), and the complaining driver given a complicated procedure for turning the "feature" off.

Please fix!!