bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#40421: 26.2; (And 27.0.90) Inconsistent fontifying in c-mode


From: Alan Mackenzie
Subject: 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@muc.de> writes:
> > In article <mailman.96.1585962545.2644.bug-gnu-emacs@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).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]