From: Daniel Colascione <dancol@dancol.org>
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: Sat, 21 Mar 2015 04:36:07 -0700 [thread overview]
Message-ID: <550D57A7.5040107@dancol.org> (raw)
In-Reply-To: <20150321105841.GA3001@acm.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 4960 bytes --]
On 03/21/2015 03:58 AM, Alan Mackenzie wrote:
> Hello, Daniel.
>
> On Fri, Mar 20, 2015 at 06:06:55PM -0700, Daniel Colascione wrote:
>> On 03/20/2015 05:00 PM, Alan Mackenzie wrote:
>>>> The existence of font-lock-extend-after-change-region-function is an
>>>> error on my part (More specifically the result of a weakness on my part:
>>>> when you requested this feature, I added
>>>> font-lock-extend-region-function (which was the right fix) and
>>>> reluctantly accepted to also add
>>>> font-lock-extend-after-change-region-function just out of tiredness of
>>>> arguing that it was the wrong solution).
>
>>> Yes, it was an exhausting discussion back in 2006. But
>>> f-l-extend-after-change-r-f works well. If you change the interface to
>>> have only font-lock-extend-region-functions, then you rule out what
>>> somebody (was it Daniel?) recently called "edge triggered" fontification,
>>> leaving only "level triggered".
>
>>> AWK Mode (if not others) uses edge triggered fontification: For the
>>> calculation of its FL region, it uses `beg' and `end' from
>>> before-change-functions and `beg', `end', and `old-len' from
>>> after-change-functions. If f-l-extend-after-change-r-f vanishes, some
>>> other means will have to be found to transmit this info to Font Lock -
>>> the ugly advice used by earlier Emacs versions, for example.
>
>> Level-triggered fontification is the only correct scheme.
>
> Can you offer any evidence, or argumentation for this opinion? As I
> said, edge-triggered fontification works in AWK Mode and works well. I'm
> not quite sure at the moment whether the other CC Mode modes use it.
If fontification depends on recent buffer history, then fontification
depends on recent buffer history. That's non-determinism. I think it
ought to be obvious why we want to highlight the same characters with
the same faces no matter how those characters came to be in the buffer.
>> You don't need fine-grained control over the font-lock region.
>
> Major modes need absolute control over where font-locking analysis starts
> - they must be able to chose a position with a neutral syntactic context.
> For example, when Font Lock asks for fontification starting in the
> inside of a C++ declaration, C++ Mode needs to be able to say STOP! GO
> BACK! CARRY ON!
The mode can start analyzing wherever it wants. There is no rule saying
that a mode's font-locking functions can't look at buffer positions
before `beg'. font-lock is telling you were it wants you to apply
fontification. You can go back further than that to analyze.
This analysis does not requiring that we forbid font-lock from
arbitrarily extending the region. Why can't cc-mode figure out a
"neutral syntactic position" before an arbitrary point?
>> You need better cache invalidation.
>
> When, where, of what?
Whatever you're trying to achieve by constricting the font-lock region,
you can achieve equally well by maintaining the right caches of buffer
context and consulting these caches when servicing font-lock
fontification requests.
>> Font-lock can ask for the right to ask for the fontification of any
>> range of characters. If I want to, I can install customization that
>> changes the font-lock region to a whole paragraph, a whole defun, or a
>> whole file. None of that should matter.
>
> Of course. But AFTER that selection, the major mode decides where to
> start analysing based on the selection. As I pointed out to Stefan, we
> don't distinguish between "place to start analysing" and "place to start
> applying face properties", so we can only talk about "the Font Lock
> region". I think the critical point is: Several things can choose,
> expand (?or contract) a region to fontify. But the major mode must be
> the last entity that does so.
Like I said, the mode can analyze whatever buffer text it wants. Why
does the analysis region (which is implicit in program logic) depend on
the font-lock region?
>> Some modes might have caches that reflect buffer contents --- they
>> should invalidate these caches in before- and after-change-functions,
>> before font-lock even runs.
>
> Not quite sure exactly what sort of caches you're thinking about, but
> they will get updated, rather than invalidated, in the
> before/after-change-functions functions, surely?
>
>> Let me put it another way: a highlighter's job is to find the correct
>> face for a given buffer position. In order to not drive the user insane,
>> that face must be a function solely of the contents of the buffer and
>> cached information about the contents of the buffer. Otherwise,
>> fontification will change depending on scrolling, jit-lock chunk size,
>> and other factors. None of these things should affect the faces that we
>> ultimately apply to characters.
>
> Of course. But they affect the way we calculate those faces.
Why?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-03-21 11:36 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 [this message]
2015-03-21 2:29 ` Stefan Monnier
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=550D57A7.5040107@dancol.org \
--to=dancol@dancol.org \
--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.