emacs-devel
[Top][All Lists]
Advanced

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

Re: Limits of multiline font-lock


From: Michael Heerdegen
Subject: Re: Limits of multiline font-lock
Date: Thu, 19 Sep 2019 04:05:13 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Adam Porter <address@hidden> writes:

> You might be interested in this package I published recently.  It
> implements depth-based syntax highlighting for Lisp and some other
> languages.
>
> https://github.com/alphapapa/prism.el

Nice.  Could it go to Gnu Elpa?

> I had to deal with similar issues about multiline font-locking.  After
> reading the manual section about it a few times, I managed to come up
> with a solution that works fairly well, although I'm sure it's quite
> primitive: I add a function to font-lock-extend-region-functions which
> extends the font-lock region forward and backwards before the matching
> function is called.  I don't know if it's the optimal way to do it--the
> manual mentioned that there are a few ways--but it seems to work.
>
> However, I have discovered a performance issue in the case of sexps that
> span large portions of the buffer (e.g. in my init files, I have some
> large use-package forms that contain many functions and span hundreds of
> lines).  If I could solve that, it would be great, but it works fine for
> most code.

If you use `font-lock-extend-region-functions', all of font-lock uses
the extended region, right?  I guess basing your functionality on
jit-lock-register could be better.  If finding the beginning-of-defun
and identifying the levels is what causes the main cost, it wouldn't
help much, however.

My use case is a bit simpler since I only have to deal with Lisp.  What
modes does prism support btw?  What are reasons why some languages are
not supported?

> Please let me know if you have any suggestions.  Sometimes font-locking
> feels like an arcane art.  :)

Ok, I've not come that far yet ;-)


Michael.



reply via email to

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