Thursday, December 15, 2016

Re: Command z doesn't work

On Wednesday, November 16, 2016 at 9:15:17 AM UTC-8, Eric Calvayrac wrote:
> Le mardi 15 novembre 2016 01:03:16 UTC+1, Gary Johnson a écrit :
> > 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
>
> 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

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!!

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

No comments: