From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Michael Heerdegen <michael_heerdegen@web.de>
Cc: Emacs Development <emacs-devel@gnu.org>
Subject: Re: Limits of multiline font-lock
Date: Mon, 16 Sep 2019 15:00:17 -0400 [thread overview]
Message-ID: <jwvftkwf51d.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87sgoxjgpb.fsf@web.de> (Michael Heerdegen's message of "Mon, 16 Sep 2019 01:13:52 +0200")
> 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
next prev parent reply other threads:[~2019-09-16 19:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-14 17:07 Limits of multiline font-lock Michael Heerdegen
2019-09-15 12:28 ` Stefan Monnier
2019-09-15 23:13 ` Michael Heerdegen
2019-09-16 19:00 ` Stefan Monnier [this message]
2019-09-18 3:23 ` Michael Heerdegen
2019-09-18 21:13 ` Adam Porter
2019-09-19 2:05 ` Michael Heerdegen
2019-09-19 2:36 ` Adam Porter
2023-10-07 7:30 ` Adam Porter
2023-10-14 4:06 ` Michael Heerdegen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvftkwf51d.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=michael_heerdegen@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.