Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]

[Alan Mackenzie]

Hi, Stephan.

On Thu, 10 Mar 2005, Stefan Monnier wrote:

>> We talked about it in bug-cc-mode just after CC Mode 5.30 had been
>> released.  (Subject: Advising in cc-awk.el and namespace   Date: Wed, 09
>> Jul 2003 13:20:20 -0400).  I drew attention then (Jul 2003) to the patch
>> I had submitted in 2002, which you acknowledged.  However, the topic of
>> conversation drifted onto why jit-lock consumed so much processor power.

>Ah...topic drift.  Sorry about not being more careful.

I think it was more me that derailed the topic, but it was a long time
ago.

>>> Could you explain some more about your two cases (the one in awk and
>>> the one in the subject of this article): - how do they use your new
>>> before-font-lock-after-change-function hook?

[ .... ]

>> The patch I proposed would achieve this result via a user supplied
>> function.

>Well my question was really about "how" rather than "why": what does the
>elisp hook code look like for each of the two cases.

Sorry, I think I was a bit confused in my last post.  We might be talking
at cross purposes.  The "before-font-lock-after-change-function-hook"
never made it into any released code.  The advice around
font-lock-after-change-function, etc., got into cc-awk.el.

>>> - why can't they use the font-lock-multiline property?

[ .... ]

>> Also, font-lock-multiline doesn't (yet?) exist in XEmacs, so I'd need to
>> implement a second solution for XEmacs if f-l-multiline was used.  CC
>> Mode still supports Emacs 20.x, and I think I found that f-l-multiline
>> was introduced later than 20.1 (though I can't remember exactly).

>Your new hook won't exist in Emacs-20 either, so this seems irrelevant to
>the discussion at hand.  It just risks drifting the topic.

Hmm.  Yes, but-  If it got into Emacs now, in 6 or 7 years time
major-moders could with good conscience say "we're now dropping support
for all versions previous to 22.1", just like we recently said "we're
dropping support for Emacs 19.xx, so as to use text properties".  It's
just a fact of life that major modes can't really use "new" elisp
features until they've penetrated fully into the installed user base -
after several years and several releases.  But that's no reason for not
making these enhancements.

[ .... ]

>> I think, as I have done since 2002, that the major-mode should be able
>> to supply functions to determine the start and end of the region to be
>> fontified.   It seems a natural and idiomatic Emacsy way of doing
>> things.

>You may be right, but I'd like to see your code first, to see how easy and
>robust it is to use your hook.

I re-posted my tentative 2002 patch here last night.  Or did you mean
something else?  I think it's robust enough, but it could certainly do
with some tidying up.  To use it, one must merely set a buffer local
variable to the major-mode's function, this function being supplied the
after-change's BEGIN END and OLD-LEN, and returning (NEW-BEGIN .
NEW-END).  I think that variable would be better called
`font-lock-get-region-function' than the
`before-font-lock-after-change-function' I proposed back then.

>On a side note, I'm wondering why you go through so much trouble with
>the "unmatched opening quote" in AWK.  No other mode does that AFAIK,
>even though pretty much every major mode in lisp/progmodes/ has pretty
>much the same need AFAICT.  Does it have to do with something specific
>to AWK, or is it non-specific and maybe it should be done for all modes?

No, it was a pure act of unadulterated joyous hacking.  It wasn't
difficult in AWK, a line oriented language, because the "safe place" from
which to begin font-locking is merely the most recent BOL which isn't
preceded by a \.  In C, it would be somewhat trickier, but not too
difficult.

I think this putting of warning-face on unmatched quotes would be a good
idea generally.  Not stunningly important in itself, but one of these
minor details, the sum total of which makes Emacs such a joy to use.

>        Stefan

-- 
Alan Mackenzie (Munich, Germany)