bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: 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@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]