unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: JD Smith <jdtsmith@gmail.com>
Cc: 71345@debbugs.gnu.org, Dmitry Gutov <dmitry@gutov.dev>
Subject: bug#71345: Feature: unleash font-lock's secret weapon; handle Qfontified = non-nil
Date: Tue, 04 Jun 2024 17:52:31 -0400	[thread overview]
Message-ID: <jwved9cl7ld.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <798B70AF-69BD-479E-992E-5CE9B4924820@gmail.com> (JD Smith's message of "Tue, 4 Jun 2024 11:38:05 -0400")

> In other words, for many cases there would in fact not be much
> property management work.  This leads naturally to considering more
> complicated cases, with several additional fontification functions all
> interoperating.  The property work will grow quickly (though I also
> outlined some ideas to keep it under control, which probably already
> occurred to you).

In theory, yes, but in practice it's not clear that's relevant.
Also, I think it's worth distinguishing the API from its implementation.

The question being whether the API is flexible enough for clients to
clearly express their needs while at the same time making it possible
for jit-lock to provide the functionality efficiently enough without
resorting to an oracle (even though the implementation at any given time
may suffer inefficiencies in some cases).

> As long as the additional property management costs are well below the
> savings you reap from not having repeated the unnecessary work, this would
> be a positive outcome.  The 2-5ms I mention is the cost for me of running
> "one large backend" over one chunk — namely font-lock-fontify-region with
> treesitter backing.  In my scenario of bar updates resulting from point
> motion, this represents purely wasted work.  So if the additional "property
> management" costs per chunk are, say, 100x below that, you are safely in
> "well worth it" territory.

That probably depends if your position-dependent backend does just

    (jit-lock-flush (point-min) (point-max) #'my-pd-backend)

or on the contrary if it's careful to do something like

    (jit-lock-flush (min my-pd-old-beg (my-pd-new-beg-estimate))
                    (max my-pd-old-end (my-pd-new-end-estimate))
                    #'my-pd-backend)

> Agreed that could be an issue.  In practice keyword-based fontification can
> lead to these same sorts of conflicts for non trivial FACE forms too.
> So backends would need to ensure the changes they are making in the buffer
> are interoperable with the other likely backends (in particular font-lock).

Because a given buffer can have several (window-)points,
position-dependent highlighting will ideally want to be added via
(window-specific) overlays rather than text-properties.

> This means other backends would still need to add to
> font-lock-extra-managed-props any unusual properties they will apply
> (or do the equivalent on their own during unfontify).

No: `font-lock-extra-managed-props` is a variable that belongs to
font-lock, not jit-lock.  `font-lock` is *one* backend of jit-lock.
Other backends will have to use something else (and should use other
text-properties or should use overlays (or make sure font-lock is not
used), otherwise you'll get into conflicts with font-lock).

If we want to allow backends that are not independent (e.g. your PD
highlighting that has to run after font-lock), then it make the API more
complex, since `jit-lock-flush` on the font-lock backend would have to
know to also flush the PD backend.

> '(F) '(F A) '(F B) '(F C) '(F A B)  '(F A C) '(F B C)  '(F A B C)
> So jit-lock-fontify-now's job has gotten quite challenging, as it decides
> over what region to apply a particular backend, say A.

I think the code would loop over chunks of text where the property is
`eq` (e.g. using `next-single-property-change`).  Then within each such
chunk of text it would iterate over either all backends (and skip
those mentioned in the `already-fontified` text-property) or over the
`pending` property backends.  That seems easy enough.


        Stefan






  reply	other threads:[~2024-06-04 21:52 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-03 16:35 bug#71345: Feature: unleash font-lock's secret weapon; handle Qfontified = non-nil JD Smith
2024-06-03 16:56 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-03 21:14   ` JD Smith
2024-06-04  1:44     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-04 12:08       ` JD Smith
2024-06-04 14:15         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-04 15:38           ` JD Smith
2024-06-04 21:52             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-06-04 22:41               ` JD Smith
2024-06-05 11:29                 ` Eli Zaretskii
2024-06-05 14:02                   ` JD Smith
2024-06-05 14:53                     ` Eli Zaretskii
2024-06-05 15:52                       ` JD Smith
2024-06-05 17:00                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-05 17:24                         ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-05 11:24               ` Eli Zaretskii
2024-06-05 14:05                 ` JD Smith
2024-06-05 16:28                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-05 16:38                   ` Eli Zaretskii
2024-06-05 16:59                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-05 17:52                       ` Eli Zaretskii
2024-06-05 18:13                         ` JD Smith
2024-06-07  3:27                         ` JD Smith

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwved9cl7ld.fsf-monnier+emacs@gnu.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=71345@debbugs.gnu.org \
    --cc=dmitry@gutov.dev \
    --cc=jdtsmith@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).