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: Wed, 26 Apr 2006 09:36:35 -0400 [thread overview]
Message-ID: <87psj48opg.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <Pine.LNX.3.96.1060426074539.345D-100000@acm.acm> (Alan Mackenzie's message of "Wed, 26 Apr 2006 08:30:25 +0000 (GMT)")
>>>> I'm not saying the hook is a kludge: I'm saying the code that uses it is
>>>> a kludge, compared to the code that uses font-lock-multiline.
>>> OK. I feel that existing code in AWK Mode is natural. (OK, I wrote it,
>>> so I'm not in a position to judge it dispassionately, but ...). It notes
>>> the logical EOL before a change. It notes the logical EOL after a
>>> change. The later one is the end position for fontification.
>> Why doesn't the BOL before change matter?
> Maybe it does/would do in some major modes. It happens not to have any
> effect in AWK.
>> Why does the EOL before change matter?
> Because a buffer change can alter this EOL's syntactic context.
But why does it matter?
Honestly, neither explanation seems very clear to me. I don't know what
others think, but this is an example of the complexity in your code.
You end up having to discuss various scenarios to justify your code, which
leaves the reader with the lingering question "but are all the relevant
scenarios covered?".
Clearly, we 're biased, but I find that the code using font-lock-multiline
doesn't suffer from such problems. It does suffer from the fact that you
have to trust font-lock's use of the font-lock-multiline property, but if
you assume it works, then all you have to do is "place the property on the
chunk of text that needs to be refontified if any part gets changed".
> font-lock-keywords. The purpose of this structure is to fontify strings
> matching specific regular expressions. Using it to expand the region to
> be font-locked at a future fontification seems utterly disconnected with
> this purpose.
My sample code using the ".*\\(\\\\\n.*\\)*" regexp was just a quick way to
show you what it could look like without having to delve into your code.
Check my cc-awk patch: it shows what typically happens in practice, which is
that you place the put-text-property right where you add the face (or
syntax-table property), so it's a lot more natural.
>> There two issues about multiline elements:
>> - properly notice them when they appear
>> - properly *re*fontify them when they change
> I cannot bring myself to consider the extension of a font lock region as
> "the manipulation of a multiline element".
I don't understand what you're saying here.
> It just feels too contorted. I have always understood the term "multiline
> element" to mean an element within the font-lock region which crosses
> a line boundary.
IIUC, that's how I understand it as well, except I wouldn't restrict it to
the "font-lock region".
>> The first is taken care of by font-lock-fontify-region-function.
> The AWK Mode regular expressions, even those that can straddle line
> breaks, match just fine without having to turn on the f-l-multiline
> variable.
I don't see how my text and yours are related here.
>> The second talks about *re*fontification, so it's natural that it would
>> involves saving some info during fontification for the next time around.
> I think I would agree, except that font-lock brutally erases these
> properties at every fontification, only to have to recalculate them.
> This wastes processor time, probably quite a lot of it.
No it doesn't *particularly* "waste processor time quite a lot": it's just
what font-lock does for a living: erase text-properties and the re-add them
(usually it only does it for `face', sometimes it does it for `syntax-table'
and/or `font-lock-multiline', and it can do that for other properties (see
font-lock-extra-managed-props)).
> What is the point of doing this, unless there has been a buffer change?
If font-lock really happens to remove a font-lock-multiline property, it
means that somebody placed it there before. Since this property is normally
placed during font-locking, it implies that we're actually *re*fontifying.
*Re*fontification normally takes place in response to a buffer change.
So, the "removal + re-addition" of the font-lock-multiline property (just
like any other property managed by font-lock) indeed only happens if there
has been a buffer change.
>> Doing it in a-c-f is fundamentally not the right place since it doesn't
>> know whether and how the changed text was fontified: it works, of
>> course, but it's not particularly more natural.
> To know how text is to be refontified, you need to know how it has been
> changed.
The font-lock-multiline property is a "living" proof that this is not true.
Stefan
next prev parent reply other threads:[~2006-04-26 13:36 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
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 [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87psj48opg.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 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.