Re: Limits of multiline font-lock

[Michael Heerdegen <michael_heerdegen@web.de>]

Stefan Monnier <monnier@iro.umontreal.ca> 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.