[Top][All Lists]

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

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

From: Dmitry Gutov
Subject: Re: Scrolling commands and skipping redisplay, was: Re: emacs rendering comparisson between emacs23 and emacs26.3
Date: Fri, 10 Apr 2020 17:45:43 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 10.04.2020 09:47, Eli Zaretskii wrote:
Cc: 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.

Not even about the last patch I sent?

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

And that's what my last patch helps it avoid doing, by default.

Speaking of the loss of precision, though. You said you'd never make that choice, and yet you recommend the use of jit-lock-defer-time. It has the very same problem, doesn't it?

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.

When I said "worse", I didn't mean to say "slower", I meant worse in how it looks. Performance-wise, jit-lock-defer-time=0 and fast-but-imprecise-scrolling=t work about the same here.

And I'd like for jit-lock-defer-time=0 to work better, so we can remove the extra customization option, but it's just not there yet.

reply via email to

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