Mode-specific font lock delays

Mode-specific font lock delays

[Björn Lindqvist]

Hello emacsers!

In the mode I'm working on, font locking is getting laggy when
operating on large buffers. Possibly because the regexps I've written
for highlighting aren't very good and could use some tune-up by some
experts. But it is quick enough for most buffers. So what I'm looking
for is a way to defer font-locking so that it only occurs when nothing
else is happening which should prevent emacs from becoming laggy.

I've found a few variables in the jit-lock-* namespace which I've
tried to tweak. What I've found worked the best was setting
jit-lock-defer-time to a value like 0.5-1.5 which completely
eliminates all lag. But there are two problems:

1) Changing the variable is not mode-specific, but changes how
font-lock operates on all buffers. That's not right as I want the
increased defer time to only apply to this mode's buffers.
2) When a file is opened, there is a flicker as font-lock waits for
the timeout before highlighting the buffer. It would be much better if
there was no delay for the first highlighting pass.

Can these two problems be solved? If so, how? It would be nice if
font-lock had some builtin auto-tuning so that if it notices that if
the highlighting passes are taking a long time to run, it increases
the delay between them.


-- 
mvh/best regards Björn Lindqvist

Re: Mode-specific font lock delays

[Stefan Monnier]

> 1) Changing the variable is not mode-specific, but changes how
> font-lock operates on all buffers. That's not right as I want the
> increased defer time to only apply to this mode's buffers.

Indeed, it was designed as a (global) user-option, not something decided
by the major mode.

> 2) When a file is opened, there is a flicker as font-lock waits for
> the timeout before highlighting the buffer. It would be much better if
> there was no delay for the first highlighting pass.

Hmmm... jit-lock currently doesn't distinguish the "first pass" at all.
Also I'm not sure if ignoring the jit-lock-defer for the "first pass"
would result in good behavior for you: it'd be laggy not just when
displaying the window the first time, but also everytime a new part of
the buffer becomes visible.

> Can these two problems be solved?

So far the experience has been that font-lock can be made fast enough
that those things aren't needed.


        Stefan

Re: Mode-specific font lock delays

[Björn Lindqvist]

2016-09-04 15:34 GMT+02:00 Stefan Monnier <monnier@iro.umontreal.ca>:
>> 1) Changing the variable is not mode-specific, but changes how
>> font-lock operates on all buffers. That's not right as I want the
>> increased defer time to only apply to this mode's buffers.
>
> Indeed, it was designed as a (global) user-option, not something decided
> by the major mode.

Perhaps it could be made mode-specific then. :)

>> 2) When a file is opened, there is a flicker as font-lock waits for
>> the timeout before highlighting the buffer. It would be much better if
>> there was no delay for the first highlighting pass.
>
> Hmmm... jit-lock currently doesn't distinguish the "first pass" at all.
> Also I'm not sure if ignoring the jit-lock-defer for the "first pass"
> would result in good behavior for you: it'd be laggy not just when
> displaying the window the first time, but also everytime a new part of
> the buffer becomes visible.

Ah I see. I thought font-lock highlighted the whole buffer when you
opened a file. That it delays highlighting parts of a buffer until you
scroll into it, I didn't know. If there was a way to force font-lock
to highlight the whole buffer I would use that because it doesn't
matter so much if opening buffers takes 300 ms or so more. It's only
when you interact with the buffer that highlighting lag becomes an
issue.

>> Can these two problems be solved?
>
> So far the experience has been that font-lock can be made fast enough
> that those things aren't needed.

These are the font-locking rules for the mode I'm working on:
https://github.com/factor/factor/blob/master/misc/fuel/factor-mode.el#L443
I'm not able to figure out how to make them faster. But if you or
anyone else can I'd be happy. :)


-- 
mvh/best regards Björn Lindqvist

Re: Mode-specific font lock delays

[Stefan Monnier]

> Ah I see. I thought font-lock highlighted the whole buffer when you
> opened a file. That it delays highlighting parts of a buffer until you
> scroll into it, I didn't know. If there was a way to force font-lock
> to highlight the whole buffer I would use that because it doesn't
> matter so much if opening buffers takes 300 ms or so more.

    (setq font-lock-support-mode nil)

would do that, pretty much (i.e. would stop use of jit-lock).

>> So far the experience has been that font-lock can be made fast enough
>> that those things aren't needed.
> These are the font-locking rules for the mode I'm working on:
> https://github.com/factor/factor/blob/master/misc/fuel/factor-mode.el#L443
> I'm not able to figure out how to make them faster. But if you or
> anyone else can I'd be happy. :)

I'd recommend you use M-x profiler-start RET and friends to try and
figure out where the problem comes from.

Also I recommend you try and think which part could take time that
depends on the size of the buffer: normally jit-lock will only fontify
the part of the buffer that changed or that is displayed, which does not
depend on the buffer size but rather on the window size.  So if you see
a slowdown in large buffers, it means some of the rules you use take
a time that depends on the buffer size.
Normally regexps shouldn't take time that depends on the buffer-size
either (they can take very long for some specific text, but that only
depends on the text being matched, not the total buffer text).  So think
of rules which might do more than just match a regexp, and which might
instead look at the surrounding context (e.g. try to find the beginning
of the surrounding function).


        Stefan