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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36421 in the body.
You can then email your comments to 36421 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andrea Cardaci <cyrus.and <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Having some text with face height > 1.0 causes scroll-step to be
 ignored
Date: Fri, 28 Jun 2019 18:19:58 +0200

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Message #8 received at 36421 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Andrea Cardaci <cyrus.and <at> gmail.com>
Cc: 36421 <at> debbugs.gnu.org
Subject: Re: bug#36421: Having some text with face height > 1.0 causes
 scroll-step to be ignored
Date: Fri, 28 Jun 2019 21:11:15 +0000

On Fri, Jun 28, 2019 at 4:27 PM Andrea Cardaci <cyrus.and <at> 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.  */);

Message #11 received at 36421 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Cardaci <cyrus.and <at> gmail.com>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36421 <at> debbugs.gnu.org
Subject: Re: bug#36421: Having some text with face height > 1.0 causes
 scroll-step to be ignored
Date: Sat, 29 Jun 2019 01:29:54 +0200

[Message part 1 (text/plain, inline)]

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 <at> gmail.com> wrote:

> On Fri, Jun 28, 2019 at 4:27 PM Andrea Cardaci <cyrus.and <at> 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.  */);
>

[Message part 2 (text/html, inline)]

Message #14 received at 36421 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Cardaci <cyrus.and <at> gmail.com>
Cc: 36421 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: Re: bug#36421: Having some text with face height > 1.0 causes
 scroll-step to be ignored
Date: Sat, 29 Jun 2019 10:35:57 +0300

tags 36421 notabug
thanks

> From: Andrea Cardaci <cyrus.and <at> gmail.com>
> Date: Sat, 29 Jun 2019 01:29:54 +0200
> Cc: 36421 <at> 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.

Message #19 received at 36421 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36421 <at> debbugs.gnu.org, pipcet <at> gmail.com,
 Andrea Cardaci <cyrus.and <at> gmail.com>
Subject: Re: bug#36421: Having some text with face height > 1.0 causes
 scroll-step to be ignored
Date: Sat, 29 Jun 2019 21:55:02 +0200

[Message part 1 (text/plain, inline)]

On Sat, Jun 29, 2019 at 9:37 AM Eli Zaretskii <eliz <at> 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.

[Message part 2 (text/html, inline)]

Message #22 received at 36421 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Cardaci <cyrus.and <at> gmail.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 36421 <at> debbugs.gnu.org,
 Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#36421: Having some text with face height > 1.0 causes
 scroll-step to be ignored
Date: Sun, 30 Jun 2019 00:43:07 +0200

On Sat, Jun 29, 2019 at 9:37 AM Eli Zaretskii <eliz <at> 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.

Message #25 received at 36421 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 36421 <at> debbugs.gnu.org, pipcet <at> gmail.com, cyrus.and <at> gmail.com
Subject: Re: bug#36421: Having some text with face height > 1.0 causes
 scroll-step to be ignored
Date: Sun, 30 Jun 2019 17:55:32 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Sat, 29 Jun 2019 21:55:02 +0200
> Cc: Andrea Cardaci <cyrus.and <at> gmail.com>, 36421 <at> debbugs.gnu.org, pipcet <at> 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.

Message #28 received at 36421 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36421 <at> debbugs.gnu.org, pipcet <at> gmail.com, cyrus.and <at> gmail.com
Subject: Re: bug#36421: Having some text with face height > 1.0 causes
 scroll-step to be ignored
Date: Sun, 30 Jun 2019 19:07:36 +0200

[Message part 1 (text/plain, inline)]

On Sun, Jun 30, 2019 at 4:55 PM Eli Zaretskii <eliz <at> 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.

[Message part 2 (text/html, inline)]

Message #31 received at 36421 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Andrea Cardaci <cyrus.and <at> gmail.com>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
 36421 <at> debbugs.gnu.org, Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#36421: Having some text with face height > 1.0 causes
 scroll-step to be ignored
Date: Thu, 04 Jul 2019 16:11:18 -0400

Andrea Cardaci <cyrus.and <at> 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

Message #36 received at 36421-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36421-done <at> debbugs.gnu.org, pipcet <at> gmail.com,
 Andrea Cardaci <cyrus.and <at> gmail.com>
Subject: Re: bug#36421: Having some text with face height > 1.0 causes
 scroll-step to be ignored
Date: Mon, 16 Sep 2019 05:08:30 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> tags 36421 notabug
> thanks
>
> > From: Andrea Cardaci <cyrus.and <at> gmail.com>
> > Date: Sat, 29 Jun 2019 01:29:54 +0200
> > Cc: 36421 <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.