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

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

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?]

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