From: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: bug-cc-mode@gnu.org, emacs-pretest-bug@gnu.org, emacs-devel@gnu.org
Subject: Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]
Date: Tue, 01 Aug 2006 15:23:54 -0400 [thread overview]
Message-ID: <jwv64hcgtg8.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <20060801194800.GA1647@muc.de> (Alan Mackenzie's message of "Tue, 1 Aug 2006 20:48:00 +0100")
> It seems that the identification of the "safe place" (in a previously
> unfontified region) needs to be done by a function essentially the same
> as font-lock-extend-region-function, since f-l-multiline properties
> haven't yet been applied. In that case, what is the advantage in using
> f-l-multiline at all?
As opposed to using what? Remember f-l-multiline is about
/rehighlighting/. Think of it as *de*highlighting. I.e. find the places
where there used to be a multiline element but not any more.
> It's going to be more code. Might it, for
> example, be faster?
It's expected to be faster than recomputing this extended region in
before-change-function (since it's the only place where you can do it
otherwise: in after-change-function it's too late (unless you saved the
info somewhere) because the buffer text may not contain the pertinent
info).
>> > Maybe you're right here. But care would be needed to ensure that
>> > there is some boundary between adjacent f-l-multiline regions, such
>> > as in this sort of thing:
>> > foo =
>> > 3 ;bar =
>> > /* ^^ */
>> > 4 ;
>> Yes, that's a problem. I don't even think the current code handles it
>> right.
> Again, this problem doesn't happen with the f-l-extend-region-function
> approach.
[ Not sure what you mean by f-l-extend-region-function, BTW. Is it the
current f-l-extend-region-function in Emacs-CVS, or is it some future
thingy that will be called from f-l-refontify-region?
The current f-l-extend-region-function can't help with
/identification/ any more than f-l-multiline. ]
I expect that the difference is not in the approaches but in their
particular implementation at a particular moment in time.
> When you load that file (having stripped the leading "> >>" from each
> line ;-), only the first 8 "defined"s get fontified. (Up to byte 500
> (jit-lock-chunk-size), perhaps?) If you set font-lock-support-mode to
> nil, the whole caboodle is (at least to begin with) fontified right.
I.e. it's a problem of /identification/, so of course f-l-multiline won't
help you.
> The point I was trying to make was that locating the "safe place" can be
> a long-winded slow operation - that in a piece of code like the above
> (which isn't untypical), the strategy of placing f-l-multiline properties
> might cause this expensive analysis to be done several times per buffer
> change.
I don't understand: the costly operation to find the safe place is what you
need for /identification/. Once you've done that, the f-l-multiline
property allows you to store the resulting info (which you computed for
/identification/, not for f-l-multiline) so you won't have to recompute
it later when deciding what to dehighlight.
Stefan
next prev parent reply other threads:[~2006-08-01 19:23 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1G3OAq-0004WV-P1@fencepost.gnu.org>
2006-07-23 14:26 ` [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++] Alan Mackenzie
2006-07-24 3:11 ` Stefan Monnier
2006-07-24 13:33 ` Alan Mackenzie
2006-07-24 14:36 ` Stefan Monnier
2006-07-24 19:29 ` Alan Mackenzie
2006-07-24 20:43 ` Stefan Monnier
2006-07-24 22:29 ` Alan Mackenzie
2006-07-24 22:30 ` Stefan Monnier
2006-07-24 14:35 ` Stefan Monnier
2006-07-31 22:04 ` Alan Mackenzie
2006-07-31 22:03 ` Stefan Monnier
2006-08-01 9:21 ` Alan Mackenzie
2006-08-01 14:55 ` Stefan Monnier
2006-08-01 19:48 ` Alan Mackenzie
2006-08-01 19:23 ` Stefan Monnier [this message]
2006-08-03 8:45 ` Alan Mackenzie
2006-08-03 15:12 ` Stefan Monnier
2006-07-31 23:59 ` Richard Stallman
2006-08-01 7:59 ` Alan Mackenzie
2006-08-01 8:32 ` David Kastrup
2006-08-01 20:09 ` Richard Stallman
2006-08-01 8:06 ` Romain Francoise
2006-08-01 20:09 ` Richard Stallman
2006-08-02 9:38 ` Aidan Kehoe
2006-08-02 9:57 ` David Kastrup
2006-08-02 10:28 ` Aidan Kehoe
2006-08-02 11:57 ` David Kastrup
2006-08-02 12:52 ` Aidan Kehoe
2006-08-02 13:21 ` David Kastrup
2006-08-02 13:31 ` Aidan Kehoe
2006-08-02 14:02 ` David Kastrup
2006-08-02 13:59 ` Stefan Monnier
2006-08-02 14:12 ` Aidan Kehoe
2006-08-02 14:14 ` David Kastrup
2006-08-02 21:20 ` Richard Stallman
2006-08-03 9:17 ` Alan Mackenzie
2006-08-03 8:42 ` David Kastrup
2006-08-03 8:54 ` Aidan Kehoe
2006-08-03 19:15 ` Richard Stallman
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=jwv64hcgtg8.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=bug-cc-mode@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=emacs-pretest-bug@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.