From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Alan Mackenzie <acm@muc.de>
Cc: 20146@debbugs.gnu.org
Subject: bug#20146: font-lock-extend-jit-lock-region-after-change: results are discarded instead of being returned.
Date: Fri, 20 Mar 2015 22:29:16 -0400 [thread overview]
Message-ID: <jwva8z7umd2.fsf-monnier+emacsbugs@gnu.org> (raw)
In-Reply-To: <20150321000003.GF3493@acm.fritz.box> (Alan Mackenzie's message of "Sat, 21 Mar 2015 00:00:03 +0000")
>> > Perhaps we could implement the convention that when a major mode has
>> > positively set the font-lock region's start and end points, these should
>> > be accepted by F/J-lock, but when not, F/J-lock should be free to alter
>> > them (as it typically does now).
>> No the core of the API is font-lock-fontify-region and it should work
>> with *any* bounds (i.e. if these need to be extended, it should be done
>> by font-lock-extend-region-function).
> However, when the bounds are set by the major mode, those bounds should
> be respected by Font Lock.
The major mode sets font-lock-extend-region-function and this functions'
result should be (and is) respected by the rest of font-lock.
But callers of font-lock-fontify-region (such as
font-lock-after-change-function, or jit-lock) can choose *any* bounds
they feel like and font-lock-fontify-region should behave correctly.
> As I pointed out to Daniel, the major mode is the expert in where
> font-locking must start
Indeed, and it instructs font-lock on how to extend the region by
setting font-lock-extend-region-function.
>> Jit-lock is implemented on top of that API and is hence free to use any
>> bounds it sees fit.
> But surely not to pass bounds to the major mode that the major mode must,
> for a second time, adjust. This is crazy.
No, it is just good design to keep complexity under check.
>> If you rely on more specific bounds being passed to
>> font-lock-fontify-region, that means you have a problem on your side.
> There is a problem, yes, but on which side it is is a matter for
> discussion. CC Mode has always relied on the specific bounds that it
> provides.
AFAIK CC-mode does not provide any bounds. Instead it uses
font-lock-extend-after-change-region-function which changes the part of
the buffer that is invalidated, which is something different.
The relationship between the two is brittle and subtle, so relying on it
is crazy and a good way to get impenetrable code with special cases
tacked on top of special cases with lots of unspecified assumptions that
only hold in common cases.
> You yourself pointed out that CC Mode is the sole user of the
> functionality for expanding FL regions.
Indeed. Others use font-lock-extend-region-function.
font-lock-extend-after-change-region-function can be useful when
a *change* on line N can cause a highlighting change on a line <N, or
when it causes a highlighting change on a line >N and you don't like the
jit-lock-context-time delay (or you want it to work correctly even if
jit-lock(-context) is not in use).
Stefan
next prev parent reply other threads:[~2015-03-21 2:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-19 23:01 bug#20146: font-lock-extend-jit-lock-region-after-change: results are discarded instead of being returned Alan Mackenzie
2015-03-20 14:20 ` Stefan Monnier
2015-03-20 16:07 ` Alan Mackenzie
2015-03-20 19:39 ` Stefan Monnier
2015-03-21 0:00 ` Alan Mackenzie
2015-03-21 1:06 ` Daniel Colascione
2015-03-21 10:58 ` Alan Mackenzie
2015-03-21 11:36 ` Daniel Colascione
2015-03-21 2:29 ` Stefan Monnier [this message]
2015-03-21 13:19 ` Alan Mackenzie
2015-03-21 14:55 ` Stefan Monnier
2015-03-21 21:03 ` Alan Mackenzie
2015-03-21 22:30 ` Stefan Monnier
2015-03-22 14:13 ` Alan Mackenzie
2015-03-23 2:01 ` Stefan Monnier
2015-03-25 17:12 ` Alan Mackenzie
2015-03-25 18:26 ` Stefan Monnier
2019-10-30 15:53 ` Lars Ingebrigtsen
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=jwva8z7umd2.fsf-monnier+emacsbugs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=20146@debbugs.gnu.org \
--cc=acm@muc.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.