From: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Richard Stallman <rms@gnu.org>, emacs-devel@gnu.org
Subject: Re: Last steps for pretesting (font-lock-extend-region-function)
Date: Fri, 21 Apr 2006 08:18:52 -0400 [thread overview]
Message-ID: <87k69jnnr6.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <Pine.LNX.3.96.1060421063748.265A-100000@acm.acm> (Alan Mackenzie's message of "Fri, 21 Apr 2006 07:58:51 +0000 (GMT)")
> Good morning, Stefan!
Good morning Alan,
> The font locking is triggered by the Change. Therefore it needs details
> of that change to determine what region of text needs refontifying. It
No, it only needs to know what the current text looks like (obviously) and
how the text was font-locked last time (to properly remove highlighting
where it doesn't apply any more). This last part canbe obtained via the
font-lock-multiline property.
> Perhaps I have truly misunderstood you. I thought you were telling me
> that some code contained within the major mode would do the
> (put-text-property ... 'font-lock-multiline ...). Are you really saying
> that the major mode merely has to set up its font-lock-keywords so that
> font-lock.el finds the right places to apply the text property?
I've generally been assuming that your code would explicitly do
a put-text-property, but indeed font-lock.el includes some code which tries
to do that for you.
>> IIUC, something like the following should do:
>> (defun c-awk-font-lock-extend-region (beg end)
>> (cons (c-awk-beginning-of-logical-line beg)
>> (c-awk-end-of-logical-line end))) <==================================
>> (setq font-lock-extend-region-function 'c-awk-font-lock-extend-region)
> That, quite demonstrably, WON'T do, since that will fail to extend the
> region to what was the end of the logical line before the change.
Of course it's not enough: it only takes care of making sure current atomic
elements are properly fontified, but not that previously atomic elements are
properly refontified. That's what the font-lock-multiline property is for.
>>>> Here is the problems I see with your proposal:
>>>> - an `extend-region' hook in font-lock-fontify-region is needed
>>> It is indeed. It is a simple patch, and I am ready and willing to write
>>> it, both for font-core.el and modes.texi. I do first ask that it's
>>> accepted in principle, though.
>> It's completely accepted. I just hope we can call it
>> "font-lock-extend-region-function".
> It has been accepted (by Richard, no less), as part of the
> font-lock-after-change-function/jit-lock-after-change. I'm proposing to
> enhance it to do the necessary region extension from within
> f-l-default-fontify-region/j-l-fontify-now too.
I consider the two as separate: the first is already installed (but I want
it removed) and the second is not installed yet, but we agree that it should
be added. I.e. I want it moved from a-c-f to f-l-d-f-r (it should not be
added to j-l-fontify-now).
>>>> - the font-lock-multiline property should be enough in all cases to make
>>>> it unnecessary to use an after-change-function hook.
>>> f-l-extend-region-function also makes a (separate) after-change-f hook
>>> unnecessary.
>> Which f-l-extend-region-function? The one called from after-change-f?
> Yes.
>> Then it's what I meant by "an after-change-function hook". The fact that
>> it's not called directly from a-c-f but via f-t-a-c-f is not very
>> important for this discussion.
> I think it's important. It saves the major mode maintainer from having
> to install his code as a separate a-c-function, and juggling them around
> to make sure they get called in the correct order.
Yes it is important in general. But this discussion is about the need to
have *any* a-c-f hook. If we need one, its place is in f-l-a-c-f, indeed,
but I argue that we don't need one, so the precise place is not really
relevant to the discussion.
>> The code will have probably the same cost whether it's called from a-c-f or
>> from font-lock, but in one case it'll be called (much) more often.
> Yes. But that calling from a-c-f is essential to correct font locking.
That's what I claim is not true.
> #########################################################################
> In AWK Mode:
> Point is at EOL 3, and we delete the backslash there.
> 1. "string \
> 2. over \
> 3. several \ <========= point is at EOL 3, about to delete the \
> 4. #lines."
OK: if the text had never been font-locked before, an a hook in
f-l-fontify-region is all we need, right? So the interesting case is when
the text had already been fontified.
In this case, the whole multiline-line has had a font-lock-multiline added,
so at this point in your example, the multiline-line is 100% covered by
a font-lock-multiline property.
> 1. In c-awk-before-change (see above for the code), we calculate
> c-awk-old-EOLL ("end of old logical line"). This give 36, (EOL 4).
Here let's say instead we don't do anything.
> 2. The \ gets deleted, and the text looks like this:
> 1. "string \
> 2. over \
> 3. several
> 4. #lines."
OK, so the whole text from line 1 to line 4 still has a font-lock-multiline
property.
> 3. jit-lock-after-change gets called as (jit-lock-after-change 26 26 1),
> which in its turn calls (c-awk-font-lock-extend-region 26 26 1). This
> "1" is the OLD-LEN, of course.
Here let's also say that instead we don't do anything special.
> 4. c-awk-f-l-e-r calls (c-awk-end-of-change-region 26 26 1). This does
> the following:
> (i) It determines the current position of the PREVIOUS end of logical
> line: (+ (- c-awk-old-EOLL old-len) (- end beg)),
> => (+ (- 36 1) (- 26 26))
> => 35
> NOTE THE USE OF old-len.
> (ii) It determines the current end of logical line:
> (c-awk-end-of-logical 26)
> => 26. This is EOL 3
> (iii) It selects the greater of these two positions:
> (max (+ (- c-awk-old-EOLL old-len) (- end beg))
> (c-awk-end-of-logical-line end))
> => (max 35 26)
> => 35.
> This 35 is the current EOL 4.
> (iv) 35 is returned to jit-lock-after-change in the cons (1 . 35), the
> extended fontification region.
> #########################################################################
Here let's also say that instead we don't do anything special.
But when we later get to f-l-fontify-region, the code looks at the
font-lock-multiline property at the boundary (i.e. at the beginning and end
of line 3) and noticies that it's set, so it extends the region to be
fontified to span all 4 lines. Just what you wanted all along.
Look ma! No old-len! Tadaaa!
If you insert text (instead of removing it), it gets a bit more interesting
(because the inserted text doesn't have a font-lock-multiline property)
but it basically works along the same lines.
Stefan
next prev parent reply other threads:[~2006-04-21 12:18 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-17 0:56 Last steps for pretesting Richard Stallman
2006-04-17 8:01 ` Ramprasad B
2006-04-17 8:37 ` Eli Zaretskii
2006-04-18 1:42 ` Richard Stallman
2006-04-19 3:54 ` Ramprasad B
2006-04-19 15:40 ` Richard Stallman
2006-04-20 5:23 ` Ramprasad B
2006-04-18 17:31 ` Bill Wohler
2006-04-19 17:02 ` Alan Mackenzie
2006-04-19 21:23 ` Stefan Monnier
2006-04-19 21:30 ` David Kastrup
2006-04-20 21:35 ` Stefan Monnier
2006-04-20 21:37 ` David Kastrup
2006-04-20 21:44 ` Stefan Monnier
2006-04-20 21:46 ` David Kastrup
2006-04-20 22:50 ` Alan Mackenzie
2006-04-19 22:43 ` Last steps for pretesting (font-lock-extend-region-function) Alan Mackenzie
2006-04-20 9:13 ` Alan Mackenzie
2006-04-20 17:46 ` Stefan Monnier
2006-04-20 18:12 ` Alan Mackenzie
2006-04-20 20:58 ` Stefan Monnier
2006-04-20 22:40 ` Alan Mackenzie
2006-04-20 23:34 ` Stefan Monnier
2006-04-21 7:58 ` Alan Mackenzie
2006-04-21 12:18 ` Stefan Monnier [this message]
2006-04-21 19:51 ` Alan Mackenzie
2006-04-21 22:28 ` Stefan Monnier
2006-04-24 19:28 ` Alan Mackenzie
2006-04-24 21:06 ` Stefan Monnier
2006-04-25 6:21 ` Ralf Angeli
2006-04-25 10:53 ` Alan Mackenzie
2006-04-25 18:37 ` Ralf Angeli
2006-04-25 22:00 ` Alan Mackenzie
2006-04-26 6:14 ` Ralf Angeli
2006-04-25 19:26 ` Stefan Monnier
2006-04-25 20:10 ` font-lock-multiline for cc-awk Stefan Monnier
2006-04-26 7:37 ` Alan Mackenzie
2006-04-26 13:55 ` Stefan Monnier
2006-04-25 19:23 ` Last steps for pretesting (font-lock-extend-region-function) Stefan Monnier
2006-04-25 20:18 ` Stefan Monnier
2006-04-25 11:33 ` Alan Mackenzie
2006-04-25 11:59 ` David Kastrup
2006-04-25 12:33 ` Stefan Monnier
2006-04-25 14:07 ` Alan Mackenzie
2006-04-25 16:05 ` Stefan Monnier
2006-04-25 16:09 ` Stefan Monnier
2006-04-25 21:52 ` Alan Mackenzie
2006-04-25 21:49 ` Alan Mackenzie
2006-04-26 4:50 ` Stefan Monnier
2006-04-24 21:20 ` Stefan Monnier
2006-04-25 7:45 ` Alan Mackenzie
2006-04-25 12:12 ` Stefan Monnier
2006-04-25 21:15 ` Alan Mackenzie
2006-04-26 4:33 ` Stefan Monnier
2006-04-26 8:30 ` Alan Mackenzie
2006-04-26 13:36 ` Stefan Monnier
2006-04-24 21:33 ` Stefan Monnier
2006-04-25 7:27 ` Alan Mackenzie
2006-04-25 12:03 ` Stefan Monnier
2006-04-25 13:14 ` Alan Mackenzie
2006-04-26 0:22 ` Miles Bader
2006-04-25 4:39 ` Tomas Zerolo
2006-04-25 19:02 ` Ralf Angeli
2006-04-25 19:30 ` Stefan Monnier
2006-04-25 20:12 ` Ralf Angeli
2006-04-25 20:26 ` Stefan Monnier
2006-04-25 20:58 ` Ralf Angeli
2006-04-25 21:11 ` Stefan Monnier
2006-04-25 22:30 ` Alan Mackenzie
2006-04-26 4:25 ` Stefan Monnier
2006-04-26 7:44 ` Alan Mackenzie
2006-04-25 22:16 ` Alan Mackenzie
2006-04-26 4:36 ` Stefan Monnier
2006-04-21 23:14 ` Drew Adams
2006-04-19 22:53 ` Last steps for pretesting (true file names in load-history?) Alan Mackenzie
2006-04-20 1:14 ` Last steps for pretesting Richard Stallman
2006-04-24 17:52 ` Richard Stallman
2006-04-20 10:54 ` Reiner Steib
2006-04-21 0:10 ` Richard Stallman
2006-04-21 5:46 ` David Kastrup
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=87k69jnnr6.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.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 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).