From: Alan Mackenzie <acm@muc.de>
To: Daniel Colascione <dancol@dancol.org>
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 10:58:41 +0000 [thread overview]
Message-ID: <20150321105841.GA3001@acm.fritz.box> (raw)
In-Reply-To: <550CC42F.7050302@dancol.org>
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.
> 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!
> You need better cache invalidation.
When, where, of what?
> 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.
> 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.
> Maybe we should have some tests that do fontification one character at a
> time, or in random order.
Now there's an idea. :-)
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2015-03-21 10:58 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 [this message]
2015-03-21 11:36 ` Daniel Colascione
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=20150321105841.GA3001@acm.fritz.box \
--to=acm@muc.de \
--cc=20146@debbugs.gnu.org \
--cc=dancol@dancol.org \
/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.