bug#36421: Having some text with face height > 1.0 causes scroll-step to be ignored

bug#36421: Having some text with face height > 1.0 causes scroll-step to be ignored

[Andrea Cardaci]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

Hi,

Basically as the title says, here's how to reproduce this:

1. start Emacs with -Q;

2. evaluate this sexp:

   (progn
     (custom-set-variables
      '(scroll-step 1)
      '(scroll-margin 0))
     (with-current-buffer (switch-to-buffer "test")
       (insert (make-string 100 ?\n)
      (propertize "XXX" 'face '(:height 2.0))
      (make-string 100 ?\n))))

3. in the newly created buffer press and keep pressed <up>.

You'll notice that the point moves to the top of the window and stays
there, but as soon as it *steps* over "XXX", the point is centered.

This is pretty annoying in my case where I use big headings in Markdown
mode.

This happens, at least, in Emacs 25.1.1, 24.5.1 and 26.2 on Linux. Please
let me know if you need additional details.


Best,

Andrea

[-- Attachment #2: Type: text/html, Size: 1158 bytes --]

bug#36421: Having some text with face height > 1.0 causes scroll-step to be ignored

[Pip Cet]

On Fri, Jun 28, 2019 at 4:27 PM Andrea Cardaci <cyrus.and@gmail.com> wrote:
> Basically as the title says, here's how to reproduce this:
>
> 1. start Emacs with -Q;
>
> 2. evaluate this sexp:
>
>    (progn
>      (custom-set-variables
>       '(scroll-step 1)
>       '(scroll-margin 0))

I think you want scroll-conservatively. Here's the documentation:

  DEFVAR_INT ("scroll-step", emacs_scroll_step,
    doc: /* The number of lines to try scrolling a window by when
point moves out.
If that fails to bring point back on frame, point is centered instead.
If this is zero, point is always centered after it moves off frame.
If you want scrolling to always be a line at a time, you should set
`scroll-conservatively' to a large value rather than set this to 1.  */);

  DEFVAR_INT ("scroll-conservatively", scroll_conservatively,
    doc: /* Scroll up to this many lines, to bring point back on screen.
If point moves off-screen, redisplay will scroll by up to
`scroll-conservatively' lines in order to bring point just barely
onto the screen again.  If that cannot be done, then redisplay
recenters point as usual.

If the value is greater than 100, redisplay will never recenter point,
but will always scroll just enough text to bring point into view, even
if you move far away.

A value of zero means always recenter point if it moves off screen.  */);

bug#36421: Having some text with face height > 1.0 causes scroll-step to be ignored

[Andrea Cardaci]

[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]

Yes, thanks, I'm aware of that (and actually the issue doesn't appear if I
use a value > 100 for that variable), but it does a different thing, for
example it does not center anymore the next word when I use interactive
search and that's something nice to have.

Moreover, it looks like a bug nevertheless...

On Fri, Jun 28, 2019, 11:11 PM Pip Cet <pipcet@gmail.com> wrote:

> On Fri, Jun 28, 2019 at 4:27 PM Andrea Cardaci <cyrus.and@gmail.com>
> wrote:
> > Basically as the title says, here's how to reproduce this:
> >
> > 1. start Emacs with -Q;
> >
> > 2. evaluate this sexp:
> >
> >    (progn
> >      (custom-set-variables
> >       '(scroll-step 1)
> >       '(scroll-margin 0))
>
> I think you want scroll-conservatively. Here's the documentation:
>
>   DEFVAR_INT ("scroll-step", emacs_scroll_step,
>     doc: /* The number of lines to try scrolling a window by when
> point moves out.
> If that fails to bring point back on frame, point is centered instead.
> If this is zero, point is always centered after it moves off frame.
> If you want scrolling to always be a line at a time, you should set
> `scroll-conservatively' to a large value rather than set this to 1.  */);
>
>   DEFVAR_INT ("scroll-conservatively", scroll_conservatively,
>     doc: /* Scroll up to this many lines, to bring point back on screen.
> If point moves off-screen, redisplay will scroll by up to
> `scroll-conservatively' lines in order to bring point just barely
> onto the screen again.  If that cannot be done, then redisplay
> recenters point as usual.
>
> If the value is greater than 100, redisplay will never recenter point,
> but will always scroll just enough text to bring point into view, even
> if you move far away.
>
> A value of zero means always recenter point if it moves off screen.  */);
>

[-- Attachment #2: Type: text/html, Size: 2398 bytes --]

bug#36421: Having some text with face height > 1.0 causes scroll-step to be ignored

[Eli Zaretskii]

tags 36421 notabug
thanks

> From: Andrea Cardaci <cyrus.and@gmail.com>
> Date: Sat, 29 Jun 2019 01:29:54 +0200
> Cc: 36421@debbugs.gnu.org
> 
> Yes, thanks, I'm aware of that (and actually the issue doesn't appear if I use a value > 100 for that variable),
> but it does a different thing, for example it does not center anymore the next word when I use interactive
> search and that's something nice to have.
> 
> Moreover, it looks like a bug nevertheless...

It is not a bug.  scroll-step works in units of the canonical line
height, not of the actual height of the line that needs to be scrolled
into the view.

In your case, when the line of double height is scrolled by the amount
of pixels that are equal to the height of the frame's default face,
point winds up in a partially visible line, so Emacs recenters to fix
that.

If you have a lot of higher-than-default lines, and you don't like the
effect of scroll-conservatively, then my suggestion is to set
scroll-conservatively to 2 or 3.

Btw, why do you find recentering annoying?  It's the default Emacs way
of bringing the next windowful of text into view together with some
context.  Scrolling by just one line is sub-optimal because you don't
see all of the context: the text below the last line is not visible.

In general, all the scroll-* options except scroll-conservatively
don't guarantee you won't see recentering in some situations.  That's
because scroll-conservatively is an expensive option, it slows down
scrolling, in some cases considerably.  The other options are much
faster, but you "pay" for that by sometimes seeing Emacs recenter.

bug#36421: Having some text with face height > 1.0 causes scroll-step to be ignored

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

On Sat, Jun 29, 2019 at 9:37 AM Eli Zaretskii <eliz@gnu.org> wrote:

> Btw, why do you find recentering annoying?  It's the default Emacs way
> of bringing the next windowful of text into view together with some
> context.  Scrolling by just one line is sub-optimal because you don't
> see all of the context: the text below the last line is not visible.

I don't think there's any simple answer to that. I remember discussing this
in emacs-devel long ago (back when the new font backends where introduced
and line-by-line scrolling was unable to keep with typing <down>
repeatedly).

The answer, I suspect, is just that some of us are wired that way. You see
it as recentering bringing up new context, I see it as forcing my visual
cortex to scramble to go to the center of the window to re-locate the line
I was looking at. That's not only slower than just looking at new lines as
they appear at the bottom. but also quite uncomfortable.

The effect is so severe that, if Emacs only had recentering and
line-by-line scrolling were impossible, it would literally be unusable for
me. In fact, I think setting line-by-line scrolling was the very first
thing I set up in Emacs, back in 1998 when I started using it. Had not
found the options to do it, Emacs would've been gone from my computer at
once.

So count me as someone very grateful of the hard effort you put back then
to make it work efficiently.

[-- Attachment #2: Type: text/html, Size: 1612 bytes --]

bug#36421: Having some text with face height > 1.0 causes scroll-step to be ignored

[Andrea Cardaci]

On Sat, Jun 29, 2019 at 9:37 AM Eli Zaretskii <eliz@gnu.org> wrote:

> In your case, when the line of double height is scrolled by the amount
> of pixels that are equal to the height of the frame's default face,
> point winds up in a partially visible line, so Emacs recenters to fix
> that.

The explanation makes sense, thanks.

> If you have a lot of higher-than-default lines, and you don't like the
> effect of scroll-conservatively, then my suggestion is to set
> scroll-conservatively to 2 or 3.

It's much better this way (set to 2), there are still some
*unpleasant* moments where the point is not exactly on the bottom (by
a fraction of line height) and some others where the point is scrolled
up by one entire line. But I guess this unavoidable, maybe I should
just stop worrying and love the recentering...

> Btw, why do you find recentering annoying?  It's the default Emacs way
> of bringing the next windowful of text into view together with some
> context.  Scrolling by just one line is sub-optimal because you don't
> see all of the context: the text below the last line is not visible.

Juanma Barranquero summarized my point perfectly.

bug#36421: Having some text with face height > 1.0 causes scroll-step to be ignored

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 29 Jun 2019 21:55:02 +0200
> Cc: Andrea Cardaci <cyrus.and@gmail.com>, 36421@debbugs.gnu.org, pipcet@gmail.com
> 
> > Btw, why do you find recentering annoying?  It's the default Emacs way
> > of bringing the next windowful of text into view together with some
> > context.  Scrolling by just one line is sub-optimal because you don't
> > see all of the context: the text below the last line is not visible.
> 
> I don't think there's any simple answer to that. I remember discussing this in emacs-devel long ago (back
> when the new font backends where introduced and line-by-line scrolling was unable to keep with typing
> <down> repeatedly).
> 
> The answer, I suspect, is just that some of us are wired that way. You see it as recentering bringing up new
> context, I see it as forcing my visual cortex to scramble to go to the center of the window to re-locate the line I
> was looking at. That's not only slower than just looking at new lines as they appear at the bottom. but also
> quite uncomfortable.

This assumes that Emacs is used for prolonged scrolling through
buffers, one line at a time.  That is something that happens to me
only very seldom, read: never.  Emacs is an editor, not a pager; and
if I ever need to page through a buffer, I do it with C-v and its ilk,
i.e. with scroll commands, not with commands that move point.

bug#36421: Having some text with face height > 1.0 causes scroll-step to be ignored

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

On Sun, Jun 30, 2019 at 4:55 PM Eli Zaretskii <eliz@gnu.org> wrote:

> This assumes that Emacs is used for prolonged scrolling through
> buffers, one line at a time.

Not really. It assumes that for some of us, even one single scrolling with
recentering is less comfortable than moving line by line.

But anyway, that's the greatness of Emacs: no two people use it the same
way.

[-- Attachment #2: Type: text/html, Size: 538 bytes --]

bug#36421: Having some text with face height > 1.0 causes scroll-step to be ignored

[Noam Postavsky]

Andrea Cardaci <cyrus.and@gmail.com> writes:

>> If you have a lot of higher-than-default lines, and you don't like the
>> effect of scroll-conservatively, then my suggestion is to set
>> scroll-conservatively to 2 or 3.
>
> It's much better this way (set to 2), there are still some
> *unpleasant* moments where the point is not exactly on the bottom (by
> a fraction of line height) and some others where the point is scrolled
> up by one entire line. But I guess this unavoidable, maybe I should
> just stop worrying and love the recentering...

It looks like scroll-down-line does the right thing, maybe a wrapping
command like this would work for you:

    (defun previous-and-maybe-scroll-line (&optional arg)
      (interactive "^p")
      (when (< (line-beginning-position 0) (window-start))
        (condition-case ()
            (scroll-down-line arg)
          (beginning-of-buffer nil))) 
      (previous-line arg))

    (define-key global-map [up] 'previous-and-maybe-scroll-line)

    ;; Corresponding [down] command left as exercise for reader

bug#36421: Having some text with face height > 1.0 causes scroll-step to be ignored

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> tags 36421 notabug
> thanks
>
> > From: Andrea Cardaci <cyrus.and@gmail.com>
> > Date: Sat, 29 Jun 2019 01:29:54 +0200
> > Cc: 36421@debbugs.gnu.org
> >
> > Yes, thanks, I'm aware of that (and actually the issue doesn't appear if I use a value > 100 for that variable),
> > but it does a different thing, for example it does not center anymore the next word when I use interactive
> > search and that's something nice to have.
> >
> > Moreover, it looks like a bug nevertheless...
>
> It is not a bug.  scroll-step works in units of the canonical line
> height, not of the actual height of the line that needs to be scrolled
> into the view.

Since this is notabug, I'm also closing it now.

Best regards,
Stefan Kangas