GNU bug report logs - #40421
26.2; (And 27.0.90) Inconsistent fontifying in c-mode

Previous Next

Package: emacs;

Reported by: Rolf Ade <rolf <at> pointsman.de>

Date: Sat, 4 Apr 2020 01:09:01 UTC

Severity: normal

Tags: notabug

Found in version 26.2

Done: Noam Postavsky <npostavs <at> gmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40421 in the body.
You can then email your comments to 40421 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#40421; Package emacs. (Sat, 04 Apr 2020 01:09:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Rolf Ade <rolf <at> pointsman.de>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 04 Apr 2020 01:09:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Rolf Ade <rolf <at> pointsman.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.2; (And 27.0.90) Inconsistent fontifying in c-mode
Date: Sat, 04 Apr 2020 03:08:30 +0200
Recipt:

emacs -Q

Insert:

/* 11 */
EXTERN int		XML_GetCurrentByteCount(XML_Parser parser);
/* 12 */
EXTERN enum XML_Status	XML_SetBase(XML_Parser parser, const XML_Char *base);
/* 13 */
EXTERN const XML_Char *	 XML_GetBase(XML_Parser parser);
/* 14 */
EXTERN int		XML_GetSpecifiedAttributeCount(XML_Parser parser);
/* 15 */

and M-x c-mode. The font-look seems randomly. Some EXTERN colered, some
not, some function names black, some blue.

The whole (small) file is here
http://tdom.org/index.html/raw/generic/tdomDecls.h?name=cccb9227. With
this syntactically correct file (at least gcc and clang consume it
without complain) there is similiar font-lock flicker around the lines
commented with 12, 13, 14.

I report this (and see it) on my working-place emacs-26.2 but have
verified, that a freshly build emacs-27.0.90 shows the same behaviour.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#40421; Package emacs. (Sat, 04 Apr 2020 09:10:01 GMT) Full text and rfc822 format available.

Message #8 received at 40421 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Rolf Ade <rolf <at> pointsman.de>
Cc: 40421 <at> debbugs.gnu.org
Subject: Re: bug#40421: 26.2; (And 27.0.90) Inconsistent fontifying in c-mode
Date: 4 Apr 2020 09:09:19 -0000
Hello, Rolf.

In article <mailman.96.1585962545.2644.bug-gnu-emacs <at> gnu.org> you wrote:

> Recipt:

> emacs -Q

> Insert:

> /* 11 */
> EXTERN int              XML_GetCurrentByteCount(XML_Parser parser);
> /* 12 */
> EXTERN enum XML_Status  XML_SetBase(XML_Parser parser, const XML_Char *base);
> /* 13 */
> EXTERN const XML_Char *  XML_GetBase(XML_Parser parser);
> /* 14 */
> EXTERN int              XML_GetSpecifiedAttributeCount(XML_Parser parser);
> /* 15 */

> and M-x c-mode. The font-look seems randomly. Some EXTERN colered, some
> not, some function names black, some blue.

Yes.  The problem here is that these declarations aren't syntactically
correct C.  To C Mode, "EXTERN" just looks like an ordinary identifier,
not a macro which (presumably) expands to "extern".

I would recommend you to use CC Mode's "noise macro" facility here.
(See the CC Mode manual.)  With this, you would tell CC Mode that
"EXTERN" just "expands to nothing", and thus won't interfere with the
syntactic analysis.  One way to do this is to set c-noise-macro-names in
a hook function, probably c-mode-common-hook.  Another way (if you don't
have many source files) would be to set that variable in a file local
variables section (see the Emacs manual) - for example, put the
following at the end of your C file:

    /* Local Variables: */
    /* c-noise-macro-names: ("EXTERN") */
    /* END: */

.  Then restart C Mode with M-x c-mode.  The fontification should now
look OK.

> The whole (small) file is here
> http://tdom.org/index.html/raw/generic/tdomDecls.h?name=cccb9227. With
> this syntactically correct file (at least gcc and clang consume it
> without complain) there is similiar font-lock flicker around the lines
> commented with 12, 13, 14.

Thanks for taking the trouble to reduce the problem to a minimal test
case.  That's appreciated.

> I report this (and see it) on my working-place emacs-26.2 but have
> verified, that a freshly build emacs-27.0.90 shows the same behaviour.

-- 
Alan Mackenzie (Nuremberg, Germany).





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#40421; Package emacs. (Fri, 10 Apr 2020 00:51:01 GMT) Full text and rfc822 format available.

Message #11 received at 40421 <at> debbugs.gnu.org (full text, mbox):

From: Rolf Ade <rolf <at> pointsman.de>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 40421 <at> debbugs.gnu.org
Subject: Re: bug#40421: 26.2; (And 27.0.90) Inconsistent fontifying in c-mode
Date: Fri, 10 Apr 2020 02:50:12 +0200
Hello Alan,

Alan Mackenzie <acm <at> muc.de> writes:
> In article <mailman.96.1585962545.2644.bug-gnu-emacs <at> gnu.org> you wrote:
>
>> Recipt:
>
>> emacs -Q
>
>> Insert:
>
>> /* 11 */
>> EXTERN int              XML_GetCurrentByteCount(XML_Parser parser);
>> /* 12 */
>> EXTERN enum XML_Status  XML_SetBase(XML_Parser parser, const XML_Char *base);
>> /* 13 */
>> EXTERN const XML_Char *  XML_GetBase(XML_Parser parser);
>> /* 14 */
>> EXTERN int              XML_GetSpecifiedAttributeCount(XML_Parser parser);
>> /* 15 */
>
>> and M-x c-mode. The font-look seems randomly. Some EXTERN colered, some
>> not, some function names black, some blue.
>
> Yes.  The problem here is that these declarations aren't syntactically
> correct C.  To C Mode, "EXTERN" just looks like an ordinary identifier,
> not a macro which (presumably) expands to "extern".

To that, or, depending on the build evironment, to something similar,
yes.

I can understand, that c-mode doesn't get this right. But part of the
point was the apparent randomly switching of the fontification. Getting
the colors wrong is one thing (but c-mode don't even got it wrong, for
the first handful of function prototypes), but getting it wrong
inconstently irritates particularly.

But, yes ...

> I would recommend you to use CC Mode's "noise macro" facility here.
> (See the CC Mode manual.)  With this, you would tell CC Mode that
> "EXTERN" just "expands to nothing", and thus won't interfere with the
> syntactic analysis.  One way to do this is to set c-noise-macro-names in
> a hook function, probably c-mode-common-hook.  Another way (if you don't
> have many source files) would be to set that variable in a file local
> variables section (see the Emacs manual) - for example, put the
> following at the end of your C file:
>
>     /* Local Variables: */
>     /* c-noise-macro-names: ("EXTERN") */
>     /* END: */
>
> .  Then restart C Mode with M-x c-mode.  The fontification should now
> look OK.

... that works well, thanks.

Sorry for the noise.

>> The whole (small) file is here
>> http://tdom.org/index.html/raw/generic/tdomDecls.h?name=cccb9227. With
>> this syntactically correct file (at least gcc and clang consume it
>> without complain) there is similiar font-lock flicker around the lines
>> commented with 12, 13, 14.
>
> Thanks for taking the trouble to reduce the problem to a minimal test
> case.  That's appreciated.
>
>> I report this (and see it) on my working-place emacs-26.2 but have
>> verified, that a freshly build emacs-27.0.90 shows the same behaviour.




Added tag(s) notabug. Request was from Noam Postavsky <npostavs <at> gmail.com> to control <at> debbugs.gnu.org. (Mon, 13 Apr 2020 13:58:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 40421 <at> debbugs.gnu.org and Rolf Ade <rolf <at> pointsman.de> Request was from Noam Postavsky <npostavs <at> gmail.com> to control <at> debbugs.gnu.org. (Mon, 13 Apr 2020 13:58:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#40421; Package emacs. (Mon, 13 Apr 2020 18:34:01 GMT) Full text and rfc822 format available.

Message #18 received at 40421 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Rolf Ade <rolf <at> pointsman.de>
Cc: 40421 <at> debbugs.gnu.org
Subject: Re: bug#40421: 26.2; (And 27.0.90) Inconsistent fontifying in c-mode
Date: Mon, 13 Apr 2020 18:32:57 +0000
Hello, Rolf

On Fri, Apr 10, 2020 at 02:50:12 +0200, Rolf Ade wrote:

> Hello Alan,

> Alan Mackenzie <acm <at> muc.de> writes:
> > In article <mailman.96.1585962545.2644.bug-gnu-emacs <at> gnu.org> you wrote:

> >> Recipt:

> >> emacs -Q

> >> Insert:

> >> /* 11 */
> >> EXTERN int              XML_GetCurrentByteCount(XML_Parser parser);
> >> /* 12 */
> >> EXTERN enum XML_Status  XML_SetBase(XML_Parser parser, const XML_Char *base);
> >> /* 13 */
> >> EXTERN const XML_Char *  XML_GetBase(XML_Parser parser);
> >> /* 14 */
> >> EXTERN int              XML_GetSpecifiedAttributeCount(XML_Parser parser);
> >> /* 15 */

> >> and M-x c-mode. The font-look seems randomly. Some EXTERN colered, some
> >> not, some function names black, some blue.

> > Yes.  The problem here is that these declarations aren't syntactically
> > correct C.  To C Mode, "EXTERN" just looks like an ordinary identifier,
> > not a macro which (presumably) expands to "extern".

> To that, or, depending on the build evironment, to something similar,
> yes.

> I can understand, that c-mode doesn't get this right. But part of the
> point was the apparent randomly switching of the fontification. Getting
> the colors wrong is one thing (but c-mode don't even got it wrong, for
> the first handful of function prototypes), but getting it wrong
> inconstently irritates particularly.

Sorry, I don't think I can offer anything constructive, here.  Macro
occurrences in text are difficult to handle well, since they can expand
to anything at all (or nothing).  Only if (?when) CC Mode starts doing
deeper analysis of the code, something compiler-like, is there really any
hope for anything better.

> But, yes ...

> > I would recommend you to use CC Mode's "noise macro" facility here.
> > (See the CC Mode manual.)  With this, you would tell CC Mode that
> > "EXTERN" just "expands to nothing", and thus won't interfere with the
> > syntactic analysis.  One way to do this is to set c-noise-macro-names in
> > a hook function, probably c-mode-common-hook.  Another way (if you don't
> > have many source files) would be to set that variable in a file local
> > variables section (see the Emacs manual) - for example, put the
> > following at the end of your C file:

> >     /* Local Variables: */
> >     /* c-noise-macro-names: ("EXTERN") */
> >     /* END: */

> > .  Then restart C Mode with M-x c-mode.  The fontification should now
> > look OK.

> ... that works well, thanks.

Good!  :-)

> Sorry for the noise.

Not a problem.  I'll close the bug report (as notabug).  Sorry I can't
offer anything better.

> >> The whole (small) file is here
> >> http://tdom.org/index.html/raw/generic/tdomDecls.h?name=cccb9227. With
> >> this syntactically correct file (at least gcc and clang consume it
> >> without complain) there is similiar font-lock flicker around the lines
> >> commented with 12, 13, 14.

> > Thanks for taking the trouble to reduce the problem to a minimal test
> > case.  That's appreciated.

> >> I report this (and see it) on my working-place emacs-26.2 but have
> >> verified, that a freshly build emacs-27.0.90 shows the same behaviour.

-- 
Alan Mackenzie (Nuremberg, Germany).




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 12 May 2020 11:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 5 years and 93 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.