bug#12937: 24.2; Fontification performed in 'jit-lock-defer-time' in any case (don't wait while Emacs become really idle).

bug#12937: 24.2; Fontification performed in 'jit-lock-defer-time' in any case (don't wait while Emacs become really idle).

[Oleksandr Gavenko]

I open (a very long .c file):

  emacs-bzr/trunk/src/coding.c

and hold DOWN key. Text in buffer scrolls up but with jerks (random stops of
scrolling for a little time) due to fontification actions.

From 'jit-lock-defer-time' docs:

  Idle time after which deferred fontification should take place.
  If nil, fontification is not deferred.

I would try to workaround jerks with:

  (setq jit-lock-defer-time 0.01)

and with same negative effect by (see below):

  (setq jit-lock-defer-time 3.0)

When I hold DOWN key text scrolls up with jerks again! Because fontification
performed again.

I expect that when I *hold* key Emacs in not idle (it get user input and
redisplay text!!) so don't understand why fontification take place. May be I
misunderstand idling concept in Emacs and should read manuals deeper...

Also note that fixing CC-mode is not a solution as there are many possible
external modes that can be useful but with slow fontification.

So it is good to have 'jit-lock-defer-time' behaviour that allow trick with
defer fontification.

I know some peoples use workflow when they use scroll-bars for very fast
moving around a file (to get brief look of file content). I prefer use
PageUp/PageDown keys to perform this task.

In GNU Emacs 24.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.10)
 of 2012-09-09 on trouble, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11204000

-- 
Best regards!

bug#12937: 24.2; Fontification performed in 'jit-lock-defer-time' in any case (don't wait while Emacs become really idle).

[Stefan Monnier]

> I would try to workaround jerks with:
>   (setq jit-lock-defer-time 0.01)
> and with same negative effect by (see below):
>   (setq jit-lock-defer-time 3.0)

I don't see that.  I'm not sure how you tried, it but I did

  src/emacs -Q --eval '(setq jit-lock-defer-time 0.01)' src/xdisp.c

and scrolling with page-down indeed is jerky and I see that the buffer
is getting fontified (at least occasionally).  But if I try again with

  src/emacs -Q --eval '(setq jit-lock-defer-time 0.1)' src/xdisp.c

then the scrolling is fast&smooth and it only gets fontified when
I stop scrolling.

I suspect that fontification takes place in the 0.01s case because
redisplay itself takes more than 0.01s, so after redisplay we check
timers and see that we've been idle for more than 0.01s (and there's no
input yet because my repeat rate is 30Hz).

BTW, with 0.01s the behavior is particularly poor because the redisplay
is even slower than without it: we first do a redisplay without
fontification, and then we fontify and have to redo a redisplay, so the
first redisplay is mostly wasted work.

> Also note that fixing CC-mode is not a solution as there are many possible
> external modes that can be useful but with slow fontification.

Fixing cc-mode is not a general solution, indeed, but it should also be done.


        Stefan

bug#12937: 24.2; Fontification performed in 'jit-lock-defer-time' in any case (don't wait while Emacs become really idle).

[Eli Zaretskii]

> From: Oleksandr Gavenko <gavenkoa@gmail.com>
> Date: Mon, 19 Nov 2012 22:56:26 +0200
> 
> I open (a very long .c file):
> 
>   emacs-bzr/trunk/src/coding.c
> 
> and hold DOWN key. Text in buffer scrolls up but with jerks (random stops of
> scrolling for a little time) due to fontification actions.
> 
> >From 'jit-lock-defer-time' docs:
> 
>   Idle time after which deferred fontification should take place.
>   If nil, fontification is not deferred.
> 
> I would try to workaround jerks with:
> 
>   (setq jit-lock-defer-time 0.01)
> 
> and with same negative effect by (see below):
> 
>   (setq jit-lock-defer-time 3.0)
> 
> When I hold DOWN key text scrolls up with jerks again! Because fontification
> performed again.
> 
> I expect that when I *hold* key Emacs in not idle (it get user input and
> redisplay text!!)

It depends on the auto-repeat rate of your keyboard and the speed of
your CPU.  With some combinations of those, I won't be surprised to
learn that Emacs has some idle time between auto-repeated keystrokes.

bug#12937: 24.2; Fontification performed in 'jit-lock-defer-time' in any case (don't wait while Emacs become really idle).

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I don't see that.  I'm not sure how you tried, it but I did
>
>   src/emacs -Q --eval '(setq jit-lock-defer-time 0.01)' src/xdisp.c
>
> and scrolling with page-down indeed is jerky and I see that the buffer
> is getting fontified (at least occasionally).  But if I try again with
>
>   src/emacs -Q --eval '(setq jit-lock-defer-time 0.1)' src/xdisp.c
>
> then the scrolling is fast&smooth and it only gets fontified when
> I stop scrolling.

I tried this in Emacs 27 (on a pretty fast laptop), and I got no
jerkiness when holding <down> (and things are fontified as I scroll).  I
also tried 0.001.

So is this still a problem?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#12937: 24.2; Fontification performed in 'jit-lock-defer-time' in any case (don't wait while Emacs become really idle).

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> I don't see that.  I'm not sure how you tried, it but I did
>>
>>   src/emacs -Q --eval '(setq jit-lock-defer-time 0.01)' src/xdisp.c
>>
>> and scrolling with page-down indeed is jerky and I see that the buffer
>> is getting fontified (at least occasionally).  But if I try again with
>>
>>   src/emacs -Q --eval '(setq jit-lock-defer-time 0.1)' src/xdisp.c
>>
>> then the scrolling is fast&smooth and it only gets fontified when
>> I stop scrolling.
>
> I tried this in Emacs 27 (on a pretty fast laptop), and I got no
> jerkiness when holding <down> (and things are fontified as I scroll).  I
> also tried 0.001.
>
> So is this still a problem?

More information was requested, but none was given within 6 months, so
I'm closing this bug.  If this is still an issue, please reply to this
email (use "Reply to all" in your email client) and we can reopen the
bug report.

Best regards,
Stefan Kangas