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

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

[Chong Yidong]

Does this bug still exist with latest CVS?  If so, please provide a
simple test case (I couldn't find one in your previous messages).

> Hi, this bug remains[*] and a quick look at the C++ file I am editing shows
> that most of my methods have ended up with this sort of misfontification
> somewhere.  Note that misfontification does not occur during initial
> fontification, only after editing (though not in a way I can replicate).  I
> guess sometimes it thinks function calls are part of a declaration, though it
> doesn't necessarily happen when the preceding statement is a declaration.  In
> one occurrence in my C++ file, the misfontification has occurred immediately
> after a for loop.
>
> Again, I'm asking for help.  I never got a response last time.  What do I need
> to look at to see what is going on?
>
> [*] following my revision 1.18 date: 2006-11-15 16:31:03 fix in cc-fonts.el of
> another unrelated issue in CVS Emacs, Emacs CVS fontifies the below with
> font-lock-variable-name-face, rather than font-lock-function-name-face, which
> may/may not give a pointer to where the problem lies.
>
>     _____________________________________________
>     From:   Marshall, Simon 
>     Sent:   07 September 2006 17:41
>     To:     'bug-cc-mode@gnu.org'
>     Cc:     'emacs-pretest-bug@gnu.org'
>     Subject:        Font-lock decides function call is function declaration in
>     C++
>
>     Intermittently, but for ages, Emacs CVS suddenly decides that C++ lines of
>     code of the form:
>
>             foo(bar);
>
>     Or:
>
>             foo() = bar;
>
>     Are function declarations, and puts font-lock-function-name-face on (in
>     these examples) "foo".  It seems to happen when I am editing the line in
>     question, or maybe just on a line near it.  (I think the last time it
>     appeared when I did M-^ on the line following, but I could be wrong.  There
>     is nothing wrong with the code preceding the misfontification.) 
>
>     Editing the line or lines above it do not make the fontification
>     permanently go away.  For example, if I comment out all preceding lines,
>     the fontification is removed.  However, when I remove the comments, it
>     comes back.  The only way I've found to get rid of it is to turn
>     font-lock-mode off and on. 
>
>     It's driving me mad because I can't work out what, in terms of the code
>     preceding it, is causing it to fontify in this way.  In one case, the
>     function call was the first statement in the method, and I noticed that the
>     text also had the "c-in-sws" property (as well as the "face" property). 
>     Debugging through cc-engine.el doesn't look fun and I don't know if the
>     presence of this property is a red herring.
>
>     I can't reproduce it, so I'm really asking for help.  Any ideas?  What can
>     I do to work out what is going wrong?
>
>     Simon.
>
>
>
> This email message is intended for the named recipient only. It may be
> privileged and/or confidential. If you are not the named recipient of this
> email please notify us immediately and do not copy it or use it for any
> purpose, nor disclose its contents to any other person.   
>
>  
>
> Misys Banking Systems is a trading name of Misys International Banking Systems
> Limited which is registered in England and Wales under company registration
> number 00971479 and with its registered office address at Burleigh House,
> Chapel Oak, Salford Priors, Evesham WR11 8SP.
>
>  
>
> THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU
> AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED
> CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE
> IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING.
>
> _______________________________________________
> emacs-pretest-bug mailing list
> emacs-pretest-bug@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

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

[Chong Yidong]

Does this bug still exist with latest CVS?  If so, please provide a
simple test case (I couldn't find one in your previous messages).

> Hi, this bug remains[*] and a quick look at the C++ file I am editing shows
> that most of my methods have ended up with this sort of misfontification
> somewhere.  Note that misfontification does not occur during initial
> fontification, only after editing (though not in a way I can replicate).  I
> guess sometimes it thinks function calls are part of a declaration, though it
> doesn't necessarily happen when the preceding statement is a declaration.  In
> one occurrence in my C++ file, the misfontification has occurred immediately
> after a for loop.
>
> Again, I'm asking for help.  I never got a response last time.  What do I need
> to look at to see what is going on?
>
> [*] following my revision 1.18 date: 2006-11-15 16:31:03 fix in cc-fonts.el of
> another unrelated issue in CVS Emacs, Emacs CVS fontifies the below with
> font-lock-variable-name-face, rather than font-lock-function-name-face, which
> may/may not give a pointer to where the problem lies.
>
>     _____________________________________________
>     From:   Marshall, Simon 
>     Sent:   07 September 2006 17:41
>     To:     'bug-cc-mode@gnu.org'
>     Cc:     'emacs-pretest-bug@gnu.org'
>     Subject:        Font-lock decides function call is function declaration in
>     C++
>
>     Intermittently, but for ages, Emacs CVS suddenly decides that C++ lines of
>     code of the form:
>
>             foo(bar);
>
>     Or:
>
>             foo() = bar;
>
>     Are function declarations, and puts font-lock-function-name-face on (in
>     these examples) "foo".  It seems to happen when I am editing the line in
>     question, or maybe just on a line near it.  (I think the last time it
>     appeared when I did M-^ on the line following, but I could be wrong.  There
>     is nothing wrong with the code preceding the misfontification.) 
>
>     Editing the line or lines above it do not make the fontification
>     permanently go away.  For example, if I comment out all preceding lines,
>     the fontification is removed.  However, when I remove the comments, it
>     comes back.  The only way I've found to get rid of it is to turn
>     font-lock-mode off and on. 
>
>     It's driving me mad because I can't work out what, in terms of the code
>     preceding it, is causing it to fontify in this way.  In one case, the
>     function call was the first statement in the method, and I noticed that the
>     text also had the "c-in-sws" property (as well as the "face" property). 
>     Debugging through cc-engine.el doesn't look fun and I don't know if the
>     presence of this property is a red herring.
>
>     I can't reproduce it, so I'm really asking for help.  Any ideas?  What can
>     I do to work out what is going wrong?
>
>     Simon.
>
>
>
> This email message is intended for the named recipient only. It may be
> privileged and/or confidential. If you are not the named recipient of this
> email please notify us immediately and do not copy it or use it for any
> purpose, nor disclose its contents to any other person.   
>
>  
>
> Misys Banking Systems is a trading name of Misys International Banking Systems
> Limited which is registered in England and Wales under company registration
> number 00971479 and with its registered office address at Burleigh House,
> Chapel Oak, Salford Priors, Evesham WR11 8SP.
>
>  
>
> THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU
> AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED
> CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE
> IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING.
>
> _______________________________________________
> emacs-pretest-bug mailing list
> emacs-pretest-bug@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

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

[Marshall, Simon]

> Does this bug still exist with latest CVS?  If so, please provide a
> simple test case (I couldn't find one in your previous messages).

Yes, it does, with CVS Emacs as of 05/02/2007.  Originally, I couldn't
reproduce it on demand.  That's why, originally, I was asking for help to
track it down.

But, messing around just now, I've finally managed to do it.  I can't say
that these are the only way of reproducing it, as I've seen this
misfontification in a variety of situations that do not look obviously like
these.

1.  The goal is to write the code snippet:

int main() {
  foo();
  bar();
}

emacs -Q foo.cpp
int SPC main() SPC { RET } RET C-p C-o bar();

OK so far.  Now to insert the "foo();" line:

C-a C-o foo

At this point, "foo" is fontified as a type, and "bar" as a variable.  OK.
Now:

()

The fontification of "foo" and "bar" disappears.  OK.  Now complete the
snippet:

;

Now "foo" is fontified as a variable.  This is wrong.

2.  Here's a variation.  This time, the goal is to write the code snippet:

int main() {
  foo(fubar);
  bar();
}

emacs -Q bar.cpp
int SPC main() SPC { RET } RET C-p C-o bar();

OK so far.  Now to insert the "foo(fubar);" line:

C-a C-o foo(fubar

At this point, "bar" is fontified as a type.  Not sure why, but still.  Now:

);

Now "bar" is fontified as a variable.  This is wrong.

What is worse is that in both cases I cannot get rid of the misfontification
without turning Font Lock mode off and on again.

I hope this help to fix The Most Annoying Fontification Bug Ever.  Simon.


This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person.       Misys Banking Systems is a trading name of Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.    THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING. 

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

[Chong Yidong]

"Marshall, Simon" <simon.marshall@misys.com> writes:

> emacs -Q foo.cpp
> int SPC main() SPC { RET } RET C-p C-o bar();
>
> OK so far.  Now to insert the "foo();" line:
>
> C-a C-o foo
>
> At this point, "foo" is fontified as a type, and "bar" as a variable.  OK.
> Now:
>
> ()
>
> The fontification of "foo" and "bar" disappears.  OK.  Now complete the
> snippet:
>
> ;
>
> Now "foo" is fontified as a variable.  This is wrong.

I can reproduce this now.  Note that it only happens in c++ mode, not
in plain c-mode.

Hopefully, someone familiar with the cc-mode code can debug it.

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

[Alan Mackenzie]

Hi, Simon!

On Mon, Feb 05, 2007 at 04:46:32PM -0000, Marshall, Simon wrote:
> > Does this bug still exist with latest CVS?  If so, please provide a
> > simple test case (I couldn't find one in your previous messages).

> Yes, it does, with CVS Emacs as of 05/02/2007.  Originally, I couldn't
> reproduce it on demand.  That's why, originally, I was asking for help to
> track it down.

> But, messing around just now, I've finally managed to do it.  I can't say
> that these are the only way of reproducing it, as I've seen this
> misfontification in a variety of situations that do not look obviously like
> these.

> 1.  The goal is to write the code snippet:

> int main() {
>   foo();
>   bar();
> }

> emacs -Q foo.cpp
> int SPC main() SPC { RET } RET C-p C-o bar();

> OK so far.  Now to insert the "foo();" line:

> C-a C-o foo

> At this point, "foo" is fontified as a type, and "bar" as a variable.  OK.
> Now:

> ()

> The fontification of "foo" and "bar" disappears.  OK.  Now complete the
> snippet:

> ;

> Now "foo" is fontified as a variable.  This is wrong.

It is indeed wrong.  

Further observations:
(i) The bug doesn't happen in C Mode.
The bug happens:
(ii) in Emacs 5.21.3/CC Mode 5.31.4
(iii) With jit-lock disabled (thankfully ;-)
(iv) in Emacs 5.21.3/CC Mode 5.30.3

So it seems its entirely a CC Mode bug.  I'm going to try and track it
down, though I suspect it could be quite tricky to find.  Thanks for
giving that recipe for producing the bug.

> 2.  Here's a variation.  [ snipped ]

> What is worse is that in both cases I cannot get rid of the
> misfontification without turning Font Lock mode off and on again.

M-o M-o fixes the fontification for me.

> I hope this help to fix The Most Annoying Fontification Bug Ever.
> Simon.

I think there're also other candidates for that description.  ;-(

-- 
Alan Mackenzie (Ittersbach, Germany).

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

[Marshall, Simon]

> So it seems its entirely a CC Mode bug.  I'm going to try and 
> track it down, though I suspect it could be quite tricky to 
> find.  Thanks for giving that recipe for producing the bug.

Thanks.

> > I hope this help to fix The Most Annoying Fontification Bug Ever.
> 
> I think there're also other candidates for that description.  ;-(

Don't poke the monster.

Uh-huh, he's woken.


This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person.       Misys Banking Systems is a trading name of Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.    THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING. 

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

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

[Chong Yidong]

Alan Mackenzie <acm@muc.de> writes:

> Further observations:
> (i) The bug doesn't happen in C Mode.
> The bug happens:
> (ii) in Emacs 5.21.3/CC Mode 5.31.4
> (iii) With jit-lock disabled (thankfully ;-)
> (iv) in Emacs 5.21.3/CC Mode 5.30.3
>
> So it seems its entirely a CC Mode bug.  I'm going to try and track it
> down, though I suspect it could be quite tricky to find.  Thanks for
> giving that recipe for producing the bug.

I think the problem is that when the buffer is in the state

  foo
  bar ();

foo looks like a type, so it is inserted in the cache variable
c-found-types.  When you add the "()":

  foo()
  bar();

this guess is no longer valid, but foo is not removed from
c-found-types.  Therefore, when you insert the final ";",

  foo();
  bar();

the call to foo(); is highlighted as though it were a constructor.
Note that if you do M-: (c-clear-found-types) prior to inserting the
final ";", the misfontification does not occur.

I don't know what the Right Fix is, however.

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

[Alan Mackenzie]

Hi, Chong!

On Fri, Feb 09, 2007 at 04:25:21PM -0500, Chong Yidong wrote:
> Alan Mackenzie <acm@muc.de> writes:

> I think the problem is that when the buffer is in the state

>   foo
>   bar ();

> foo looks like a type, so it is inserted in the cache variable
> c-found-types.

Exactly!  Thanks for that.

> When you add the "()":

>   foo()
>   bar();

> this guess is no longer valid, but foo is not removed from
> c-found-types.  Therefore, when you insert the final ";",

>   foo();
>   bar();

> the call to foo(); is highlighted as though it were a constructor.
> Note that if you do M-: (c-clear-found-types) prior to inserting the
> final ";", the misfontification does not occur.

> I don't know what the Right Fix is, however.

Once a variable has been inserted into c-found-types, it will stay there
almost for ever; it will stay there until re-fontification is done from
BOB (I'm not sure whether or not that also means (point-min) on a
narrowed buffer).  This permanence seems to be the fundamental problem.

To Simon: Sorry about my saying that "M-o M-o will clear the spurious
font-lock-type-face".  It only does that when point is within 16 lines of
BOB.  :-(

I think a solution might be to remove "foo" from c-found-types whenever
text is inserted/deleted in the vicinity of "foo\n bar ();" which
syntactically destroys its status as a type identifier.  I'll need to
think a lot more about this.

-- 
Alan.

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

[Stefan Monnier]

> I think a solution might be to remove "foo" from c-found-types whenever
> text is inserted/deleted in the vicinity of "foo\n bar ();" which
> syntactically destroys its status as a type identifier.  I'll need to
> think a lot more about this.

I'd be interested to know what solution you end up using.  I've bumped into
a similar problem in sml-mode where I tried to look at the infix precedence
declarations in the file while font-locking to adjust the indentation
algorithm.

The best solution I found so far is to add a special text property covering
the "infix" declaration and whose value is the symbol whose precedence and
associativity is being set, and then in font-lock-unfontify-region I begin
by looking for this special property and removing the corresponding symbols
from the precedence table.  But this failed when the whole line was deleted
since the unfontify gets called after the text (and its text-property) is
removed (i.e. too late), so I ended up using before-change-functions
instead, which seemed too costly compared to the importance of the feature,
so it's still in the "experimental" state.

Maybe a better approach is to use overlays rather than text-properties, so
they don't completely disappear if the text is removed.


        Stefan

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

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

[Chong Yidong]

Alan Mackenzie <acm@muc.de> writes:

> Once a variable has been inserted into c-found-types, it will stay there
> almost for ever; it will stay there until re-fontification is done from
> BOB (I'm not sure whether or not that also means (point-min) on a
> narrowed buffer).  This permanence seems to be the fundamental problem.
>
> I think a solution might be to remove "foo" from c-found-types whenever
> text is inserted/deleted in the vicinity of "foo\n bar ();" which
> syntactically destroys its status as a type identifier.  I'll need to
> think a lot more about this.

For the Emacs 22 release, if no simple fix is forthcoming, could we
simply get font-lock to avoid higlighting constructor functions?

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

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

[Stefan Monnier]

>> Once a variable has been inserted into c-found-types, it will stay there
>> almost for ever; it will stay there until re-fontification is done from
>> BOB (I'm not sure whether or not that also means (point-min) on a
>> narrowed buffer).  This permanence seems to be the fundamental problem.
>> 
>> I think a solution might be to remove "foo" from c-found-types whenever
>> text is inserted/deleted in the vicinity of "foo\n bar ();" which
>> syntactically destroys its status as a type identifier.  I'll need to
>> think a lot more about this.

> For the Emacs 22 release, if no simple fix is forthcoming, could we
> simply get font-lock to avoid higlighting constructor functions?

Or to not try to auto-learn types,


        Stefan

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

[Marshall, Simon]

> >> Once a variable has been inserted into c-found-types, it will stay
there
> >> almost for ever; it will stay there until re-fontification is done from
> >> BOB (I'm not sure whether or not that also means (point-min) on a
> >> narrowed buffer).  This permanence seems to be the fundamental problem.
> >> 
> >> I think a solution might be to remove "foo" from c-found-types whenever
> >> text is inserted/deleted in the vicinity of "foo\n bar ();" which
> >> syntactically destroys its status as a type identifier.  I'll need to
> >> think a lot more about this.
> 
> > For the Emacs 22 release, if no simple fix is forthcoming, could we
> > simply get font-lock to avoid higlighting constructor functions?
> 
> Or to not try to auto-learn types,

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.

Perhaps cc-mode should only try to learn types when fontifying the whole
buffer?

Simon.


This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person.       Misys Banking Systems is a trading name of Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.    THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING. 

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

[Stuart D. Herring]

> 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.

It's worse than that.  Inserting a new letter that changes "foo", or
transposing two characters 3k back in the buffer that cause the whole
region to become a comment, 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.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

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

[Stefan Monnier]

>> 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.

> It's worse than that.  Inserting a new letter that changes "foo", or
> transposing two characters 3k back in the buffer that cause the whole
> region to become a comment, 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.

Yes, of course, the case of commenting code needs to be handled as well, but
re-using the font-lock machinery makes it "somewhat painless".


        Stefan

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

[Alan Mackenzie]

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).

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

[Alan Mackenzie]

Hi, Chong and Stefan!

On Sun, Feb 11, 2007 at 06:18:34PM -0500, Chong Yidong wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Once a variable has been inserted into c-found-types, it will stay
> > there almost for ever; it will stay there until re-fontification is
> > done from BOB (I'm not sure whether or not that also means
> > (point-min) on a narrowed buffer).  This permanence seems to be the
> > fundamental problem.

> > I think a solution might be to remove "foo" from c-found-types
> > whenever text is inserted/deleted in the vicinity of "foo\n bar ();"
> > which syntactically destroys its status as a type identifier.  I'll
> > need to think a lot more about this.

> For the Emacs 22 release, if no simple fix is forthcoming, could we
> simply get font-lock to avoid higlighting constructor functions?

Give me a few more days, please!

int main () {
   foo(               <=================
   bar();
}

I think I can now see how to do this removal of "foo" from c-found-types:
After experimenting with C++ Mode, I conjecture that each "critical" use
of "foo" is marked with one of the values (c-decl-id-start
c-decl-type-start) for the property c-type.  (Hint: it's not at the
buffer position you might expect.)

If this proves true, or almost true, it will be easy enough to amend CC
Mode's before/after-change function to remove these identifiers from
c-found-types.

Give me a few more days to try this out, please!

-- 
Alan Mackenzie (Ittersbach, Germany).

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

[Stuart D. Herring]

>> 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.

Perhaps the cache should note how many times something is used?  Then the
relatively common case of

socket s;
socket_factory sf/*=...*/;
s.initializeFrom(sf);

would not remove `socket' from the cache, but typo-corrections can still
change it.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

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

[Alan Mackenzie]

Hi, Stuart!

On Mon, Feb 12, 2007 at 10:06:22AM -0800, Stuart D. Herring wrote:
> >> 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.

> Perhaps the cache should note how many times something is used?  Then the
> relatively common case of

> socket s;
> socket_factory sf/*=...*/;
> s.initializeFrom(sf);

> would not remove `socket' from the cache, but typo-corrections can still
> change it.

NO!!!  It isn't that sort of cache.  It's purely there to speed things
up, since without it, the various after-change functions would have to
analyse the source extensively for types for every character you type.

It's important that the cache contains most of the type identifiers.  It
doesn't much matter if one or two are missing.  What DOES matter is when
the cache has identifiers which aren't types (even if they once were).
This is what's causing the bug here.

I've got a clearer idea of where and how to remove ex-types than I did
last night.

> Davis

-- 
Alan.