Re: Mode-specific font lock delays

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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