Re: C font-lock bug

Re: C font-lock bug

[A Soare]

> 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 wrote it just to jump quickly to the Lisp_Type.

>  I changed the subject to reflect that this is a bug in font-lock
> for C code.

We got it. I repetead many times that.

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

That was my bug that I reported 2 times in past.

Who solved it?


Alin Soare.

Re: C font-lock bug

[Francesco Potorti`]

>>  I changed the subject to reflect that this is a bug in font-lock
>> for C code.
>
>We got it. I repetead many times that.

Just once clearly, as far as I can see in my records.  The previous
times the problem was obfuscated by references to find-tag.

>> 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.
>
>That was my bug that I reported 2 times in past.
>Who solved it?

It does not appear to be solved.  Would you try to do that?  Writing
Emacs is a cooperative effort.

Re: C font-lock bug

[A Soare]

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

This sounds strange. Look here at the messages from 1 or 2 months ago:

http://www.nabble.com/Re%3A--alinsoar%40voila.fr%3A-this-is-a-bug---tf3472154.html#a9690266

Re: C font-lock bug

[A Soare]

> >>  I changed the subject to reflect that this is a bug in font-lock
> >> for C code.
> >
> >We got it. I repetead many times that.
> 
> Just once clearly, as far as I can see in my records.  The previous
> times the problem was obfuscated by references to find-tag.
> 
> >> 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.
> >
> >That was my bug that I reported 2 times in past.
> >Who solved it?
> 
> It does not appear to be solved.  Would you try to do that?  Writing
> Emacs is a cooperative effort.
> 

When I have time! I reported this bug, not solved it. So far nobody understood that it is a bug. So your step is an important one. Writing  Emacs is a cooperative effort.

http://www.nabble.com/this-is-a-bug--tf3466628.html#a9671977
http://www.nabble.com/this-is-a-bug--tf3448811.html#a9618937



Alin Soare.

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