From: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: bug-cc-mode@gnu.org, emacs-pretest-bug@gnu.org, "Marshall,
Simon" <simon.marshall@misys.com>, Richard Stallman <rms@gnu.org>,
emacs-devel@gnu.org
Subject: Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]
Date: Mon, 24 Jul 2006 10:36:08 -0400 [thread overview]
Message-ID: <jwvmzaz5d3f.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <20060724133343.GA1111@muc.de> (Alan Mackenzie's message of "Mon, 24 Jul 2006 14:33:43 +0100")
>> >> 3. Append a space to the fourth commented line. Bug:
>> >> fontification of Foo, bar, Snafu and snafu is removed from that
>> >> line.
>> > The problem is that after a textual change, the changed line gets
>> > fontified as an atomic entity, i.e. yanked out of its context. The
>> If you placed a font-lock-multiline property on the whole thing,
>> font-lock would know not to yank that one line out of its context.
> We've already been through this at some length.
> I think we're agreed that it's not possible to put this property exactly
> where it's needed (at the boundaries of the region to fontify, and
> nowhere else) when it's needed (at the time of the change, before Font
> Lock starts fontifying).
I'm talking about this specific example, which is about refontification, not
about the original fontification. As you know, the two problems are
closely related yet separate.
>> > solution is to determine the bounds of the region to fontify by
>> > analysing the surrounding text syntactically.
>> Presumably, at the moment when Emacs fontified it correctly, it knew
>> the corresponding bounds, so it could have added the
>> font-lock-multiline property at that time, thus avoiding the need to
>> re-determine those bounds later when refontifying.
> The buffer was originally fontified as a whole, thus the corresponding
> bounds were BOB and EOB.
Is that what is called a strawman argument?
Come on, be more constructive, please.
In the pattern rules where you add the correct highlighting, you probably
have a pretty good idea about where the relevant boundaries are.
Have you taken the time to look at my cc-awk.el patch example (I mean,
other than to try and find some superficial flaw in it). It should give you
a pretty good idea of what the above paragraph refers to.
Check also my sample patch for problems number 2 and 3 for another example.
> When the buffer is changed, in the most general case, the bounds of the
> region to be refontified are going to have to be recalculated before
> fontifying.
You keep saying that, but that's not the case. When *re*fontifying, you
don't need to recalculate those context bounds, as long as you were
careful to store them (e.g. in a font-lock-multiline property) when you
knew them.
> As you are aware, I intensely dislike the notion that an entire buffer
> should have to be left constantly marked with all places where it
> fontification might have to straddle line boundaries, rather than
> determining these things as they are needed.
That's OK: your likes an dislikes only bother you. BTW the entire buffer
already needs to be left constantly marked with face information (takes
a lot more resources) as well as `fontified' information.
Try C-u C-x = a few times to get an idea.
> I also dislike being unable to specify an exact fontification region to
> Font Lock (such as the bounds of one of Simon's comments).
I don't understand what you're referring to.
Stefan
next prev parent reply other threads:[~2006-07-24 14:36 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 [this message]
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
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=jwvmzaz5d3f.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 \
--cc=rms@gnu.org \
--cc=simon.marshall@misys.com \
/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.