|
From: | Adam Porter |
Subject: | Re: Limits of multiline font-lock |
Date: | Sat, 7 Oct 2023 02:30:21 -0500 |
User-agent: | Mozilla Thunderbird |
Hi Michael,Please forgive the "blast from the past"; going through some old mail from the list I saw this message of yours that I missed.
On 9/18/19 21:05, Michael Heerdegen wrote:
Adam Porter <adam@alphapapa.net> 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.elNice. Could it go to Gnu Elpa?
Yes, I think I will submit it to GNU ELPA one of these days. It's more mature now than it was then.
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.
IIRC that performance issue turned out to be a bug elsewhere in the code; once solved, the issue with large forms spanning many lines was no longer a problem.
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?
Prism has two modes, one for whitespace-significant languages and one for all others. It seems to generally work well, especially since some recent bug fixes.
The liability, to the extent that there is one, is that syntax tables can affect how delimiters and comments are detected, and some major modes may not use them in a way that makes such detection possible, e.g. using Emacs regexps' syntax types and syntax-ppss parsing.
Now that treesitter is in Emacs, I'm guessing that it might be helpful as a backend for some languages, so I may look into that in the future.
[Prev in Thread] | Current Thread | [Next in Thread] |