emacs-devel
[Top][All Lists]
Advanced

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

Re: Scrolling commands and skipping redisplay, was: Re: emacs rendering


From: Eli Zaretskii
Subject: Re: Scrolling commands and skipping redisplay, was: Re: emacs rendering comparisson between emacs23 and emacs26.3
Date: Fri, 10 Apr 2020 09:47:30 +0300

> Cc: address@hidden, address@hidden, address@hidden, address@hidden,
>  address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Fri, 10 Apr 2020 01:17:51 +0300
> 
> You have addressed only about 30% of my previous email.

I don't have anything to say about the rest.

> > Tradeoffs of what?  You are probably scrolling in a buffer that uses
> > a single font all over, with fontifications changing only the colors.
> > While this is a very frequent scenario, it is by no means the only one
> > Emacs needs to support.  Imagine a buffer where many lines have
> > characters that become much taller than the default after
> > fontifications -- in such a buffer fast-but-imprecise-scrolling will
> > cause you get to the wrong screenful, because it will consider each
> > character to be displayed with the default face.
> 
> You will have the wrong screenful, yes. But how wrong exactly? If the 
> user floored C-v, they are not looking for precision.

Depends on what you mean by "precision".  They might very well miss
some parts of the buffer entirely, i.e. never see them on display.
This may or may not be important, depending on the use case.  An
editor is not supposed to skip portions of the buffer when scrolling
continuously.

> > We already have jit-lock-defer-time; people
> > who have slow machines are advised to set that to something like 0.1
> > or 0.25, and they can have scrolling that is way faster than with
> > fast-but-imprecise-scrolling (and with the same tradeoff of making
> > scrolling "imprecise").  Why invent kludges when we already have a
> > better solution that was there since Emacs 21?
> 
> As explained in a separate subthread, jit-lock-defer-time=0 has worse 
> side-effects than fast-but-imprecise-scrolling (while including its 
> downside). And I won't even mention values higher than 0.

Here, it behaves much better.  So maybe some other factors are at work
in your configuration.  I think we should try making the solid
solutions work as intended before we look for kludges.  The "normal"
way of doing something when Emacs is idle is by using an idle timer,
and that's what jit-lock-defer-time does.  So from my POV it is the
solution for such problems.



reply via email to

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