[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Limits of multiline font-lock

From: Stefan Monnier
Subject: Re: Limits of multiline font-lock
Date: Mon, 16 Sep 2019 15:00:17 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]