[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: |
Mon, 16 Sep 2019 01:13:52 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Stefan Monnier <address@hidden> writes:
> I think before deciding which tools to use, I think you need to figure
> out how you want to solve the fundamental difficulty:
>
> - we're inside an arbitrary buffer with your new el-search-hi-lock
> functionality enabled for a particular pattern.
Must be an emacs-lisp buffer, of course.
> - let's assume for now that currently there's no match anywhere.
> - then the user makes an edit at line N which makes the pattern match
> on lines M to M' (M < N and M' > N).
>
> How do you plan on finding this match?
Matches are always limited by bounds of the current top-level
expression. A complete re-search from the beg-of-defun of window-start
up to window-end after a change is sufficient and doable in acceptable
time (in your concrete scenario, I could even restrict the search to all
parent sexps the edited text is in - most of the time these will no ever
be more than 20 or so...these can be tested very quickly).
I already have a prototype (not based on font-lock), and it starts
refontification only after a (tiny) idle time, and the search function
is interruptable (via throw-on-input). When interrupted, the old
visible state is restored.
This works quite nicely and feels quite natural unless the search
pattern is very costly (then I currently emit a warning - the pattern
could also remove itself from the list or turn the minor mode off).
The tricky rest is now stuff that font-lock already does well. My
current implementation has problems with cases like when different
(maybe overlapping) parts of a buffer are visible in different windows,
there is a certain risk of infinite retriggering of hi-locking etc.
Thanks,
Michael.