scrolloff side effects are bothersome

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

scrolloff side effects are bothersome

Elijah Griffin
I've long used scrolloff intermittantly, but recently I tried adding it
to my vimrc. I'm finding myself unhappy now.

Straight from the scrolloff docs:

                                                *'scrolloff'* *'so'*
'scrolloff' 'so' number (default 0, set to 5 in |defaults.vim|)
                        global
                        {not in Vi}
        Minimal number of screen lines to keep above and below the cursor.
        This will make some context visible around where you are working.  If
        you set it to a very large value (999) the cursor line will always be
        in the middle of the window (except at the start or end of the file or
        when long lines wrap).
        For scrolling horizontally see 'sidescrolloff'.
        NOTE: This option is set to 0 when 'compatible' is set.

Not at all mentioned there is that the H and L movements are changed. As
someone with a long habit of using yH and yL (or >>L, or dH, etc),
trying to use scrolloff is annoying.

Consider a large file, like .../libdata/vim/vim80/doc/options.txt
You can open that file with ":help scrolloff" right now. Then try
":set scrolloff=0" <return> and "MyH", depending on screensize you get
something like "12 lines yanked". Now try ":set scrolloff=999" and then
"MyH" again. Now only the current line is yanked.

What I would *expect* and what I would like is if H and L movements were
not affected by scrolloff, and yanks, deletes, etc worked again to top
and bottom of the screen. And if actually moving to top or bottom with a
bare H or L, I'd expect the cursor to move, *and* the screen to scroll
according to scrolloff.

Doesn't this bother other people? Or does no one use scrolloff?

Elijah

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: scrolloff side effects are bothersome

Ben Fritz
On Tuesday, October 10, 2017 at 1:57:38 PM UTC-5, Eli the Bearded wrote:

> I've long used scrolloff intermittantly, but recently I tried adding it
> to my vimrc. I'm finding myself unhappy now.
>
> Straight from the scrolloff docs:
>
> *'scrolloff'* *'so'*
> 'scrolloff' 'so' number (default 0, set to 5 in |defaults.vim|)
> global
> {not in Vi}
> Minimal number of screen lines to keep above and below the cursor.
> This will make some context visible around where you are working.  If
> you set it to a very large value (999) the cursor line will always be
> in the middle of the window (except at the start or end of the file or
> when long lines wrap).
> For scrolling horizontally see 'sidescrolloff'.
> NOTE: This option is set to 0 when 'compatible' is set.
>
> Not at all mentioned there is that the H and L movements are changed. As
> someone with a long habit of using yH and yL (or >>L, or dH, etc),
> trying to use scrolloff is annoying.
>
> Consider a large file, like .../libdata/vim/vim80/doc/options.txt
> You can open that file with ":help scrolloff" right now. Then try
> ":set scrolloff=0" <return> and "MyH", depending on screensize you get
> something like "12 lines yanked". Now try ":set scrolloff=999" and then
> "MyH" again. Now only the current line is yanked.
>
> What I would *expect* and what I would like is if H and L movements were
> not affected by scrolloff, and yanks, deletes, etc worked again to top
> and bottom of the screen. And if actually moving to top or bottom with a
> bare H or L, I'd expect the cursor to move, *and* the screen to scroll
> according to scrolloff.
>
> Doesn't this bother other people? Or does no one use scrolloff?
>
> Elijah
It doesn't bother me, but I never use H/M/L commands with an operation. I only ever use them for imprecise "big jump" navigation. If I did, it would probably bother me.

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: scrolloff side effects are bothersome

C.v.St.
On 10/11/17 um 04:58 Ben Fritz wrote:
> On Tuesday, October 10, 2017 at 1:57:38 PM UTC-5, Eli the Bearded wrote:
>> I've long used scrolloff intermittantly, but recently I tried adding it
>> to my vimrc. I'm finding myself unhappy now.
...

>> What I would *expect* and what I would like is if H and L movements were
>> not affected by scrolloff, and yanks, deletes, etc worked again to top
>> and bottom of the screen. And if actually moving to top or bottom with a
>> bare H or L, I'd expect the cursor to move, *and* the screen to scroll
>> according to scrolloff.
>>
>> Doesn't this bother other people? Or does no one use scrolloff?
>>
>> Elijah
>
> It doesn't bother me, but I never use H/M/L commands with an operation. I only ever use them for imprecise "big jump" navigation. If I did, it would probably bother me.
>

Well, that really is important to know! Else I'd unknowingly ignore
lines if I'd 'yL'. And I'd expect the same behavior as Elija. The
'first', 'middle', and 'last' line should keep their meaning according
to the real screen, and only 'moving the pointer' should scroll AFTER
the move into the screen.

Stucki

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: scrolloff side effects are bothersome

Tony Mechelynck
In reply to this post by Elijah Griffin
On Tue, Oct 10, 2017 at 8:57 PM, Eli the Bearded
<[hidden email]> wrote:

> I've long used scrolloff intermittantly, but recently I tried adding it
> to my vimrc. I'm finding myself unhappy now.
>
> Straight from the scrolloff docs:
>
>                                                 *'scrolloff'* *'so'*
> 'scrolloff' 'so'        number  (default 0, set to 5 in |defaults.vim|)
>                         global
>                         {not in Vi}
>         Minimal number of screen lines to keep above and below the cursor.
>         This will make some context visible around where you are working.  If
>         you set it to a very large value (999) the cursor line will always be
>         in the middle of the window (except at the start or end of the file or
>         when long lines wrap).
>         For scrolling horizontally see 'sidescrolloff'.
>         NOTE: This option is set to 0 when 'compatible' is set.
>
> Not at all mentioned there is that the H and L movements are changed. As
> someone with a long habit of using yH and yL (or >>L, or dH, etc),
> trying to use scrolloff is annoying.
>
> Consider a large file, like .../libdata/vim/vim80/doc/options.txt
> You can open that file with ":help scrolloff" right now. Then try
> ":set scrolloff=0" <return> and "MyH", depending on screensize you get
> something like "12 lines yanked". Now try ":set scrolloff=999" and then
> "MyH" again. Now only the current line is yanked.
>
> What I would *expect* and what I would like is if H and L movements were
> not affected by scrolloff, and yanks, deletes, etc worked again to top
> and bottom of the screen. And if actually moving to top or bottom with a
> bare H or L, I'd expect the cursor to move, *and* the screen to scroll
> according to scrolloff.
>
> Doesn't this bother other people? Or does no one use scrolloff?
>
> Elijah

I don't use H/M/L but I do use PgUP/PgDn (whose effects are different)
though never with an operator. My usual 'scrolloff' setting is 6.

Experiment shows that the displayed lines don't scroll for H/M/L,
regardless of the 'scrolloff' setting, so the somewhat cryptic
sentence «Cursor is adjusted for 'scrolloff' option.» under both
":help H" and ":help L" means (IIUC) that the top and bottom are to be
understood exclusive of the 'scrolloff' lines, though there are no top
'scrolloff' lines at the top of the file and no bottom 'scrolloff'
lines at the bottom of the file. Or alternatively, that H moves the
cursor as high as possible, L as low as possible, and M halfway
between these, but in all cases without having 'scrolloff' scroll the
window contents. As you noticed, if 'scrolloff' is set very high,
H/M/L all keep the cursor on the same (middle) line but move it
horizontally to the first nonblank.

If the bottom line of the file is displayed higher than the bottom of
the window, the M line is correspondingly adjusted halfway between
that and the H line (top of the window plus possible 'scrolloff').

IMHO the present behaviour is consistent but the help could be made clearer.


Best regards,
Tony.

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: scrolloff side effects are bothersome

Elijah Griffin
Tony Mechelynck wrote:
> I don't use H/M/L but I do use PgUP/PgDn (whose effects are different)
> though never with an operator. My usual 'scrolloff' setting is 6.

I've been using H/M/L since before Vim existed. Frequently PgUp/PgDn did
not work without a manual :map in those days, and many keyboards I use
even today lack those keys. I am the sort of person who uses ssh from
a phone with an on-screen "soft" keyboard. Every motion that doesn't
require switching keyboard panes is my friend.

> Experiment shows that the displayed lines don't scroll for H/M/L,
> regardless of the 'scrolloff' setting, so the somewhat cryptic
> sentence «Cursor is adjusted for 'scrolloff' option.» under both
> ":help H" and ":help L" means (IIUC) that the top and bottom are to be
> understood exclusive of the 'scrolloff' lines, though there are no top

And as someone who has used H/M/L since before Vim existed, consulting
the H/M/L documentation for how those would behave with a "{not in Vi}"
setting didn't occur to me. {not in Vi} settings SHOULD document their
not in Vi behaviors at the setting level.

> IMHO the present behaviour is consistent but the help could be made
> clearer.

The motions H/M/L are the only ones that operate based on what is
*visible* on the screen. It is my firm belief that changing those motions
to ignore parts of the *visible* screen is seriously against the spirit
of the motions.

Elijah

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: scrolloff side effects are bothersome

Bram Moolenaar
In reply to this post by C.v.St.

Stucki wrote:

> On 10/11/17 um 04:58 Ben Fritz wrote:
> > On Tuesday, October 10, 2017 at 1:57:38 PM UTC-5, Eli the Bearded wrote:
> >> I've long used scrolloff intermittantly, but recently I tried adding it
> >> to my vimrc. I'm finding myself unhappy now.
> ...
> >> What I would *expect* and what I would like is if H and L movements were
> >> not affected by scrolloff, and yanks, deletes, etc worked again to top
> >> and bottom of the screen. And if actually moving to top or bottom with a
> >> bare H or L, I'd expect the cursor to move, *and* the screen to scroll
> >> according to scrolloff.
> >>
> >> Doesn't this bother other people? Or does no one use scrolloff?
> >>
> >> Elijah
> >
> > It doesn't bother me, but I never use H/M/L commands with an operation. I only ever use them for imprecise "big jump" navigation. If I did, it would probably bother me.
> >
>
> Well, that really is important to know! Else I'd unknowingly ignore
> lines if I'd 'yL'. And I'd expect the same behavior as Elija. The
> 'first', 'middle', and 'last' line should keep their meaning according
> to the real screen, and only 'moving the pointer' should scroll AFTER
> the move into the screen.

Hmm, it's possible to make these commands not use 'scrolloff' when an
operator is pending.  It won't be consistent with other operations
though.  But it does make sense when 'scrolloff' is a large number,
since it's then hard to estimate what text will be covered.  While the
first visible line or last visible line are easy to spot.

With this change no tests fails, so perhaps no user will have a problem
with it?  Still I worry about the inconsistency.  Als, "yH" will scroll
the text.

This change is all that's needed:

--- old/normal.c 2017-09-23 15:08:13.200518795 +0200
+++ normal.c 2017-10-11 22:16:58.927151726 +0200
@@ -5954,7 +5954,9 @@
     curwin->w_cursor.lnum = curbuf->b_ml.ml_line_count;
     }
 
-    cursor_correct(); /* correct for 'so' */
+    /* Correct for 'so', except when an operator is pending. */
+    if (cap->oap->op_type == OP_NOP)
+ cursor_correct();
     beginline(BL_SOL | BL_FIX);
 }
 


--
            ### Hiroshima 45, Chernobyl 86, Windows 95 ###

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: scrolloff side effects are bothersome

Elijah Griffin
In reply to this post by Elijah Griffin
Bram wrote:
> Hmm, it's possible to make these commands not use 'scrolloff' when an
> operator is pending.  It won't be consistent with other operations
> though.  But it does make sense when 'scrolloff' is a large number,
> since it's then hard to estimate what text will be covered.  While the
> first visible line or last visible line are easy to spot.
>
> With this change no tests fails, so perhaps no user will have a problem
> with it?  Still I worry about the inconsistency.  Als, "yH" will scroll
> the text.

I wonder, seriously, how many (if any) users of H and L had previously
run into this problem to be aware of what you consider "inconsistency".

Because as I noted yesterday, H and L are, I think, the ONLY vi
movements that are about what-is-currently-displayed. Everything else
is about searches, straight out character or line counts, marked
positions, and explicit positions.

I include find-match "%", end-of-paragraph "}", find-character "f"/"t",
etc, in "searches"; start-of-line-test "^" possibly that or else
"explicit positions" like character "|", end-of-line "$", start-of-line
"0", and end-of-file "G". And marked positions either named (eg "`a") or
implicit (eg "''") don't change depending on view or cursor position.

And I don't include any movements that are in vim, but not vi. (Not that
I can think of any relevant for this point, but I know there's a lot in
vim I don't use.)

H and L are always the top of the view and the bottom of the view. And
they change when the *window changes size*. They are nothing like the
other vi (real vi) movements. (M, too, changes with window size, but M is
not really affected by scrolloff.)

I've been using vim since just about forever, I know have vim 2.x around
in my archives, and still sometimes think about changes like "Q" becoming
"gq". But I use vim in a very vi-like way, not in a very vim-ish way. So
how vim features interact with vi features might be more concerning to me.

Elijah

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.