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

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

bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time


From: Tassilo Horn
Subject: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time
Date: Thu, 23 Apr 2015 21:53:44 +0200
User-agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> That's because the code has changed since.  Now redisplay (which
>> happens after running a command) is skipped based on the value of
>> `input-pending-p' at the beginning of the *command*, rather than
>> based on its value at the beginning of redisplay.  And jit-lock.el
>> has been changed to use (not (input-pending-p)), but only if
>> jit-lock-defer-time is 0, so the special case for 0 is new.
>
> FWIW, when I set jit-lock-defer-time to zero and lean on the PageDown
> key, I see somewhat clunky scrolling with no fontifications, until I
> release the key.

Oh, I've told you that I get the display freezes even with
jit-lock-defer-time set to zero but I've been wrong.  My error was that
I called `emacs -Q src/buffer.c', then set jit-lock-defer-time to zero
in *scratch*, and then scrolled in buffer.c.  But the effect applies
only to new buffers.

So with jit-lock-defer-time = 0, scrolling doesn't freeze the display,
and also the "no fontification problem" in bug report buffers or
byte-compilation output buffers doesn't occur anymore.

> But fontification inside the scrolling code itself still happens, I
> think.

Yes, most text that scrolls by is black on white but occassionally I can
catch sight of something reddish (a string or comment) or bluish
(function name).

Bye,
Tassilo





reply via email to

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