Re: Font-lock decides function call is function declaration in C+ +

[Alan Mackenzie <acm@muc.de>]

Evening, Stuart and Simon!

On Mon, Feb 12, 2007 at 07:53:53AM -0800, Stuart D. Herring wrote:
> > Yes, unfortunately, I think that if you try to learn types
> > on-the-fly then you will always be vulnerable to this sort of
> > problem.  The issue is that cc-mode needs to know as soon as a
> > change invalidates it as a candidate type (ie, deletion of some/all
> > of the text "foo" or interruption of the whitespace between "foo"
> > and its candidate identifier "bar").  I can think of a few ways you
> > could attempt to do it, but they are a bit intensive and far from
> > simple.

This is true, but such a way has already been built into CC Mode (by
Martin Stjernholm).  It just[*] needs a little tweaking.

[*] To the cynical - hold off a few days before commenting on this
adverb, please!

> It's worse than that.  Inserting a new letter that changes "foo", ...

is taken care of, in the commonest case.  When you type the "l" after
"foo", this replaces "foo" with "fool" in the cache c-found-types.

> ... or transposing two characters 3k back in the buffer that cause the
> whole region to become a comment, ....

is a problem throughout lots of modes in Emacs.  c-found-types doesn't
exacerbate it much (or at all?) for CC Mode.

> ... or deleting "bar", or exchanging "foo" and "bar", or merely
> exchanging 'f' and 'o', or adding #define in front of "foo", or... any
> of which could be done as one change by an appropriate Lisp helper
> function.

I think most of these can be made to work quite soon, if they don't
already.  However, you're more than welcome to test these scenarios out
and post the results here.  ;-)

> Davis

-- 
Alan Mackenzie (Ittersbach, Germany).