Re: [alinsoar@voila.fr: this is a bug?]

Re: [alinsoar@voila.fr: this is a bug?]

[A Soare]

> >I report again, becuase this bug was ignored.
> 
> In fact, I had answered to you, but received no reply.  I append the
> text of my previous mail at the end of this mail.
> 
> > I rewrite it into an easier to reproduce form:
> >1. Emacs -Q
> >2. M-. Lisp_Type <RET>
> >Select then the path to your TAGS file of your emacs.
> 
> All well until here.
> 
> >The first 4 members of this enumeration are listed in yellow color to
> >me . The last 4 members in black color .
> 
> What enumeration?  Why are the colours important?

Lisp_Type is an enumeration. And because It is preceded by M-. (i.e. by find-tag) it is clear what it means.

C font-lock bug

[Francesco Potorti`]

Sorry for the big delay, I am trying ot recover my email backlog.

>> >1. Emacs -Q
>> >2. M-. Lisp_Type <RET>
>> >Select then the path to your TAGS file of your emacs.
>> >The first 4 members of this enumeration are listed in yellow color to
>> >me . The last 4 members in black color .
>> 
>> What enumeration?  Why are the colours important?
>
>Lisp_Type is an enumeration. And because It is preceded by M-. (i.e. by
>find-tag) it is clear what it means.

At last I understand.  In fact, find-tag is completely unrelated with
this.  I changed the subject to reflect that this is a bug in font-lock
for C code.

Specifically, if you load lisp.h from the Emacs sources and look at
 enum Lisp_Type
you see that the colour of the members of the enum changes after the
fourth member.

Re: C font-lock bug

[Alan Mackenzie]

Hi, Francesco!

On Fri, Apr 27, 2007 at 12:07:34PM +0200, Francesco Potorti` wrote:
> Sorry for the big delay, I am trying ot recover my email backlog.

> >> >1. Emacs -Q
> >> >2. M-. Lisp_Type <RET
> >> >Select then the path to your TAGS file of your emacs.  The first 4
> >> >members of this enumeration are listed in yellow color to me . The
> >> >last 4 members in black color .

[ .... ]

> At last I understand.  In fact, find-tag is completely unrelated with
> this.  I changed the subject to reflect that this is a bug in font-lock
> for C code.

OK.

> Specifically, if you load lisp.h from the Emacs sources and look at
> enum Lisp_Type you see that the colour of the members of the enum
> changes after the fourth member.

Yes.  A workaround is M-o M-o.  (Yes, I _know_ you know this.  Sorry!)

This problem has been around a long time, and needs substantial work to
fix.  It happens in long enums, structs, and so on.  The font-locking
code needs to be told where to start its parsing, and after the first few
lines in a long enum, the font-locking stuff no longer knows that it's
inside an enum because the start of the enum is "too far away".

In a solution, the CC Mode font locking routines will have to determine
the place to start and stop parsing, and have to communicate this to the
Font Lock code somehow.  There have been extensive discussions on
emacs-devel about these topics.

This isn't going to get fixed for Emacs 22.  Sorry!

-- 
Alan Mackenzie (Ittersbach, Germany).

Re: [alinsoar@voila.fr: this is a bug?]

[A Soare]

> >I report again, becuase this bug was ignored.
> 
> In fact, I had answered to you, but received no reply.  I append the
> text of my previous mail at the end of this mail.

Sorry, I found all these messages in spam, and corbeille, because it was automatically deleted.

> 
> > I rewrite it into an easier to reproduce form:
> >1. Emacs -Q
> >2. M-. Lisp_Type <RET>
> >Select then the path to your TAGS file of your emacs.
> 
> All well until here.


> 
> >The first 4 members of this enumeration are listed in yellow color to
> >me . The last 4 members in black color .
> 
> What enumeration?  Why are the colours important?
> 
> What I see is that the buffer shows the lisp.h file, and the cursor is
> at the line of the definition of "enum Lisp_Type", which is what I
> expect.
> 
> >So this is a bug.
> 
> I cannot reproduce it.  After the second step of you description, what
> path do you enter?  What do you see exactly after that?  Does Emacs open
> the lisp.h file?


The problem is just about the definition of FONT LOCK of C mode.

Why the first 4 members are yellow,Lisp_Int,Lisp_Symbol,Lisp_Misc,Lisp_String,
and the last 4 members are white? This is a bug evidently in FONT LOCK.

Re: [alinsoar@voila.fr: this is a bug?]

[Francesco Potorti`]

>I report again, becuase this bug was ignored.

In fact, I had answered to you, but received no reply.  I append the
text of my previous mail at the end of this mail.

> I rewrite it into an easier to reproduce form:
>1. Emacs -Q
>2. M-. Lisp_Type <RET>
>Select then the path to your TAGS file of your emacs.

All well until here.

>The first 4 members of this enumeration are listed in yellow color to
>me . The last 4 members in black color .

What enumeration?  Why are the colours important?

What I see is that the buffer shows the lisp.h file, and the cursor is
at the line of the definition of "enum Lisp_Type", which is what I
expect.

>So this is a bug.

I cannot reproduce it.  After the second step of you description, what
path do you enter?  What do you see exactly after that?  Does Emacs open
the lisp.h file?


My previous email:
================================================================

Date: 1 Mar 2007 08:22:19 +0100
From: Francesco Potorti` <pot@gnu.org>
To: alinsoar@voila.fr
CC: "Emacs   Dev  [emacs-devel]" <emacs-devel@gnu.org>
In-reply-to: <22920027.396161172706718894.JavaMail.www@wwinf4004> (alinsoar@voila.fr)
Subject: Re: ETAGS & find-tag
Organization: 

>Do you consider normal that M-. <find-tag>
>
>jumps in order to the following definitions (of function or variable) using C-u as prefix :
>
>find-tag-hook
>find-tag-default-function
>
>but not to... find-tag?

No.  It should jump to find-tag first, then to the other ones.  In fact,
I cannot reproduce the behaviour you describe.

>I opened TAGS file, and <find-tag> was not there.

Which etags did you use?  I can see the tag whith either new or old
etags.

>Still I had created the TAGS by
>find -name *.[ch] -o -name *.el | xargs etags -

In this particular case this works, but don't do that in general,
because xargs may make two calls to etags as the consequence of too many
arguments, and in this case you would get a second TAGS overwriting the
first one without any warnings.  For Emacs, just do `make tags'.