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 10:21:47 +0100 [thread overview]
Message-ID: <20060801092147.GB1176@muc.de> (raw)
In-Reply-To: <jwv8xm9jvr7.fsf-monnier+emacs@gnu.org>
Morning, Stefan!
On Mon, Jul 31, 2006 at 06:03:41PM -0400, Stefan Monnier wrote:
> >> The patch below seems to fix number 2 and 3 for me. Someone who
> >> understands cc-fonts.el better than me and thus knows where the two
> >> "public XXX" lines are handled could probably do a similar
> >> adjustment for them.
> > At the very least, this isn't suitable for the CC Mode repository,
> > since font-lock-multiline hasn't (yet?) been implemented in XEmacs
> > or older GNU Emacsen.
> I find it quite suitable, personally, since although it indeed only
> fixes the OP's problem under Emacs-22 (and Emacs-21 if you're willing
> to set the font-lock-multiline variable to t), it won't hurt in
> Emacs-20 or XEmacs.
> Better yet: you can make it work under any old font-lock
> implementation (Emacs-19/20/21, XEmacs-??) by using
> font-lock-fontify-region-function to obey the font-lock-multiline
> property.
And yes, f-l-fontify-region-function does exist in XEmacs. :-)
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?
> > I don't know cc-fonts.el that well myself, yet, but I get the
> > feeling that putting in f-l-multiline properties like this is, at
> > best, only going to converge gradually on a working solution [to the
> > problem of CC Mode lines being fontified out of context]. How will
> > we know when every case has been covered?
> - Check every place where you set faces
> - see on which part of the buffer's text this highlighting decision
> depends
> - add a f-l-multiline property on it if it spans more than a line (or
> even: add a f-l-multiline property on it no matter what if you
> prefer it that way).
> If you've indeed checked every place where a highlighting is added,
> then you know you've covered all cases.
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 ;
> > As I've said once or twice before, I'd prefer to calculate the f-l
> > change region explicitly at each change.
> I have a hard time imagining how that's going to be very different:
> you'll have to check every possible situation to figure out which
> region to use.
:-) You're probably right there, too!
Actually, the convergence would be from a different direction: I'd start
using (I think) c-beginning-of-statement-1, which would be reliable but
unbearably sluggish, then optimise the sluggishness away with caching
mechanisms and whatnot.
> How will you know that you indeed haven't missed one possible case?
> Since the cases you care about are those handled by your highlighting
> code, I'd expect it's easier to make sure you've covered all cases if
> you add the code directly where you handle each case.
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:
There is nothing in the functions currently in cc-fonts capable of
locating the opening "# if" when one of the subsequent lines is changed.
I think I'd need to put a `c-beginning-of-statement-1' thing in the bit
of code which would apply f-l-multiline. I think I'd need to call that
function lots of times, in each fontification routine.
I think that's because we have very different conceptual models of code.
I think that having f-l-multiline code throughout the existing
cc-fonts.el would be more difficult to test (and much easier to forget
about when making other changes) than having a distinct function
c-beginning-of-font-lock-region.
> Stefan
--
Alan.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
next prev parent reply other threads:[~2006-08-01 9:21 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 [this message]
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=20060801092147.GB1176@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.