Re: Limits of multiline font-lock

[Stefan Monnier]

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

Good.

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

This makes it sound like you don't want to do it "synchronously" like
font-lock, but rather asynchronously (from a timer).  I'd tend to agree
(tho arguably, font-lock should also be done asynchronously ;-).

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

I think if you use jit-lock-register to be told about areas that need to
be (re)searched, keep them in a side-data-structure (or as
text-properties), and then in the timer you simply process this
side-data-structure, you should naturally avoid infinite retriggering of
hi-locking (assuming you're using either overlays for the actual
highlight, or you're using with-silent-modifications to avoid
needlessly retriggering jit-lock).


        Stefan