[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.