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 18:28:06 -0400 [thread overview]
Message-ID: <jwv64l2inzn.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <Pine.LNX.3.96.1060421182236.250A-100000@acm.acm> (Alan Mackenzie's message of "Fri, 21 Apr 2006 19:51:22 +0000 (GMT)")
>> 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.
> It would do this, presumably, in an after-change (or before-change)
> function, either directly on one of these hooks or called from
> font-lock-after-change.
No, it's done in font-lock-default-fontify-region.
> OK. So the font-lock-multiline property is put on exactly a region of
> text which needs fontifying atomically, yet straddles a line break. An
> after-change function (and/or a before-change function) is what will do
> this putting and erasing of f-l-multiline.
No, it's done in font-lock-default-fontify-region.
> I think it's more accurate just to say you want to remove the
> extend-region stuff from f-l-after-change. I want it to stay. :-)
> Why don't we call the thing we need in f-l-d-f-r
> "font-lock-extend-CHUNK-function", since it's more likely to be a
> jit-lock chunk than a region supplied by the user or major mode?
Since it's a hook run from font-lock-default-fontify-region, it makes sense
to call it "extend-region", don't you think? Naming (and documenting)
something based on how it is used rather than what it does is usually
a bad idea.
> What is your objection to f-l-extend-region-f in a-c-f? Is it because it
> might gobble too much processor time?
That and the fact that it's not necessary, and that to use it (as seen in
your example) you need a good bit more work/code than doing it "the other
way" (with code solely run from font-lock-default-fontify-region).
> It needs to be in j-l-fontify-now, so that that function knows what bytes
> to apply the 'fontified property to.
This is not needed for correctness. It's only a matter of avoiding
redundant work. This need wouldn't be new (it has existed since Emacs-21
becaue of font-lock-multiline) and doesn't need to be addressed right away.
>> 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.
> I can't see how a major mode can manipulate f-l-multiline properties
> anywhere BUT an a-c-f (or a before-c-f).
What about the sample solution I provided: it's all manipulated from
font-lock-keywords (i.e. from font-lock-default-fontify-region)?
>> Look ma! No old-len! Tadaaa!
> .... but some code, somewhere, sometime needs to adjust the f-l-m
> property, removing it from L4. In general, it will also need to _split_
> the text property into L1,2,3 and L4,5,... Otherwise, a f-l-m region
> could gradually engulf an entire buffer, making a nonsense of jit-lock.
> (OK, this would be an extreme situation. :-)
Yes, of course. It's done this way: font-lock-unfontify-region (called from
font-lock-default-fontify-region) removes the font-lock-mutliline property
on the whole fontified region jsut before proceeding with the actual
fontification, so the font-lock-keywords need to re-add it at those places
where it's still needed.
>> 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.
> Something, somewhere, sometime has to analyse the newly inserted code,
> putting f-l-m properties throughout it, I think, and adjusting those at
> the boundaries of the new region. Is this to be done at the time of the
> change or at the time it gets font locked? I think it has to be done at
> the change, otherwise the f-l-m settings will be wrong when it comes time
> to fontify a chunk.
Let me extend my example. In the last episode, we stopped just before
refontification was to take place and had seen that the f-l-m property was
going to make the refontification apply to all 4 lines, as needed.
The fontification will work as follows:
5. font-lock-default-fontify-region gets asked to refontify line 3.
6. it extends the refontified region at beg and at end because of the
presence of f-l-m property. So the refontified region now spans all
4 lines.
7. Prior to applying the new fontification, font-lock-unfontify-region is
called which removes all `face' properties and `font-lock-multiline'
properties on all 4 lines.
8. the actual refontification takes place, using font-lock-keywords.
During this step, the rule
(".*\\\\\n.*"
(0 (progn (put-text-property (match-beginning 0) (match-end 0)
'font-lock-multiline t)
nil)))
is used to re-add a font-lock-multiline property to the first 3 lines
(the 4th is not part of the multiline-line any more).
If we had remoed the \ on line 2 instead, the refontification would have
added the font-lock-multiline to lines 1&2 and then 2&3 (the two
separated by a \n which is does not have this property).
See, it does analyse the new text to adjust the font-lock-multiline property.
> 1. I think font-lock-extend-region-function, called as it is from
> j-l-after-change, is a good thing. It is a correct way of giving a major
> mode an opportunity to massage a fontification region. I think it should
> stay. You think it should be removed.
Yup.
> 2. f-l-d-f-r / j-l-f-now absolutely need a
> "font-lock-extend-chunk-function" functionality (regardless of its
> precise name). We agree on this.
Yup.
> 3. You have convinced me that it is possible to use the f-l-m properties.
Good.
> 4. I think that f-l-extend-region-f, called from f-l-after-change, is
> likely to be more convenient and less error prone than the direct
> manipulation of the f-l-multiline property by major mode code.
You mean adding a single put-text-property call in your font-lock-keywords
rule is more error prone than cooking up a b-c-f plus an a-c-f plus some way
to store info between the two so that the a-c-f can figure out what
happened, ...?
> 5. I suspect you think that f-l-extend-region-f is likely to consume more
> processor time than direct manipulation of the f-l-m property.
The problemis not what is done but when. after-change-fucntions get run
more often than font-lock-fontify-region.
> Is there any reason why we can't leave both methods side by side in
> the code?
Unnecessary complexity. And it will mislead people into thinking that
using a a-c-f is a good way to solve their problem.
Stefan
next prev parent reply other threads:[~2006-04-21 22:28 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 [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwv64l2inzn.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.