From: Alan Mackenzie <acm@muc.de>
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, 1 Aug 2006 20:48:00 +0100 [thread overview]
Message-ID: <20060801194800.GA1647@muc.de> (raw)
In-Reply-To: <jwvslkgh6f6.fsf-monnier+emacs@gnu.org>
'Evening, Stefan!
On Tue, Aug 01, 2006 at 10:55:41AM -0400, Stefan Monnier wrote:
> > As a matter of interest, does the f-l-multiline mechanism somehow
> > work with a _first_ fontification? Assume CC Mode has been enhanced
> > to use f-l-multiline. Say we have a buffer of C source in
> > fundamental mode (so there're no f-l-m properties on the buffer), and
> > the top of the screen is in the middle of a C construct. If we do
> > M-x c-mode, will the top line get correctly fontified?
> No, as explained in the lispref manual, to handle multiline elements,
> you have to handle both /rehighlighting/ (e.g. Simon's problem that
> started this thread) and /identification/ (e.g. what you describe here)
> and although the two are closely related, they cannot be handled in the
> same way.
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? It's going to be more code. Might it, for
example, be faster?
> The f-l-multiline property allows you to handle /rehighlighting/ but
> not /identification/.
> > 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.
> > I don't agree here; a bug report from Peter Dyballa (back in February or
> > March) gave this as an example:
> >> /* lots of things don't have <malloc.h> */
> >> /* A/UX systems include it from stdlib, from Xos.h */
> >> #ifndef VMS /* VMS hates multi-line '#if's */
> >> # if !defined(ibm032) && \
> >> !defined(__convex__) && \
> >> !(defined(vax) && !defined(ultrix)) && \
> >> !defined(mips) && \
> >> !defined(apollo) && \
> >> !defined(pyr) && \
> >> !defined(__UMAXV__) && \
> >> !defined(bsd43) && \
> >> !defined(__bsd43) && \
> >> !(defined(BSD) && (BSD >= 199103)) && \
> >> !defined(aux) && \
> >> !defined(__bsdi__) && \
> >> !defined(sequent)
> >> As the attached picture shows some "defined" keywords are not
> >> emphasised:
> I don't know whether the bug was that the `defined' keywords were not
> originally correctly fontified (problem of /identification/), or whether
> their correct highlighting was preserved when editing the text (problem of
> /rehighlighting/). If it's the former, then it's unrelated to what I'm
> talking about.
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.
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.
> > There is nothing in the functions currently in cc-fonts capable of
> > locating the opening "# if" when one of the subsequent lines is
> > changed.
> If the original highlighting was correct, then when you did this
> original highlighting you happened to know where the "# if" was located
> (even though you don't have any code that can find it in the general
> case) and you could have remembered that info by placing a
> font-lock-multiline property.
In the above example, the file has merely been loaded with C-x C-f. I
suspect that the fontification goes awry where the display code splits
the buffer into ~500 byte chunks.
> Stefan
--
Alan.
next prev parent reply other threads:[~2006-08-01 19:48 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 [this message]
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=20060801194800.GA1647@muc.de \
--to=acm@muc.de \
--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.