RE: FW: Font-lock misfontifies foo::bar in C++

RE: FW: Font-lock misfontifies foo::bar in C++

[Marshall, Simon]

> OK.  Just to clarify where I think we are - In this:
> 
>     void foo::bar()
> 
> , "foo" gets font-lock-constant-face.
> 
> (i) We both agree that this face assignment is deliberate and
>   documented: On the page "Faces" in the CC Mode manual, it says:
>   * Name qualifiers and identifiers for scope constructs are
>     fontified like labels.
>   * Label identifiers get `font-lock-constant-face' if it exists,
>     `font-lock-reference-face' otherwise.
> (ii) You're saying that fontifying "foo::" like a label is bad.
> 
> ##############################################################
> ###########
> 
> > > Example 3:
> 
> > >     foo::bar
> 
> > > "foo" doesn't specify the type of anything here either. Its 
> > > use is to tell in which scope "bar" is declared. Hence it 
> > > gets a face that is different from the type face. I call this 
> > > use "identifier qualifier".
> 
> > > To make this more obvious/precise, you could perhaps 
> > > introduce another face name variable, say 
> > > c-qualifier-face-name, and make a suitable mapping of it onto 
> > > one of the existing font-lock faces. I don't think it should 
> > > be mapped to the type face though, because it would be used 
> > > for namespace names too. In lack of better alternatives I 
> > > chose to map it as I did.
> 
> > I think c-qualifier-face-name would be a good idea, but I think it odd
to
> > pick a face for its value that is definitely wrong.  References are used
for
> > constants and labels.  Why not pick a face that is usually right, eg,
the
> > type face?
> 
> I'm at a disadvantage here, because I don't feel at all strongly about
> what the right face is for "foo::", as long as it's visually distinct.
> In fact I'd never really noticed that it was font-lock-constant-face.
> 
> You're an expert on font-lock, though.  Why would f-l-type-face be any
> better?  Martin feels quite strongly, that "foo::bar" is not using foo
> "in a type context", and has referred to Pike (one of CC Mode's other
> languages), where a constant declaration is a special case of a class
> declaration.

OK, let's take this qualifier thing at face value.  (In C++, "foo" in
"foo::bar" is a qualifier.  It is the name either of a type or a namespace.)

class CLASS;			// CLASS is in font-lock-type-face
namespace NAMESPACE;		// NAMESPACE is now in
font-lock-constant-face
void CORN::fubar();		// CORN is now in font-lock-constant-face

(In Emacs 19/20/21, CLASS, NAMESPACE and CORN are all in
font-lock-type-face.)

By the qualifier argument, CORN cannot be in the face used for type names,
because it is not used "in a type context".  But, by the same argument, it
cannot be in the face used for namespace names either, because it is not
used in a namespace context.  (a) Since CORN is fontified in the same face
as namespace names, your qualifier argument leads me to the conclusion that
the current behaviour is broken.  By the qualifier argument, if you really
wanted to distinguish between namespace names, type names and qualifiers,
you would have to use 3 distinct faces.

This leads me to my original bug report.  (b) The use of
font-lock-constant-face for either NAMESPACE or CORN is wrong, because that
face is for constants and labels.  That face is quite explicitly documented
that way.  

Therefore, by your (a) and my (b), you need to use a new face for NAMESPACE
and a new face for CORN.

To return to the qualifier argument.  The contexts are (1) a type name in a
type context, (2) a type name in a qualifier context, (3) a namespace name
in a namespace context, and (4) a namespace name in a qualifier context.
Currently, you distinguish between (1) and (2,3,4).  This is wrong
regardless of the faces used.  Personally, I do not see the value in
distinguishing between each of them (I hope you don't think that the
qualifier argument implies that you should!), or even between (1), (3) and
(2,4).  I don't buy the qualifier argument at all.  There would be too many
faces for one, and too little practical gain for another.

To return to my original report.  I originally made (1,2,3,4) be fontified
as a type name mostly for ease of implementation and performance, not
because I had a particular view of whether it was worth distinguishing
between them.  I think it would be useful to change this, so that (1,2) are
distinguished from (3,4).  But you shouldn't use font-lock-constant-face to
fontify a namespace name.  

That's why I say it would be better to fontify as a type name, at least
until type names and namespace names can be dealt with individually as I
suggest below.

(I don't see the relevance of Pike---this is just about C++.)

> > Perhaps a better solution would be to add a
> > c++-font-lock-extra-qualifiers, akin to c++-font-lock-extra-types,
> > that is a list of qualifier names.  I would suggest that, by default,
> > these could be fontified in font-lock-type-face, but perhaps you might
> > like to add a font-lock-qualifier-face to allow users (or modes) to
> > specify what they want.  For C++, this variable could default to
> > '("std") or somesuch.  
> 
> > So, by default, "foo::bar" would not cause "foo" to be fontified in any
> > face.  If the user wanted it to be fontified, they would modify
> > c++-font-lock-extra-types if it were a type or
> > c++-font-lock-extra-qualifiers if it were a namespace.
> 
> > WDYT?
> 
> OK; maybe.  But that would definitely be a new feature for CC 
> Mode 5.32, not something to slip in to 5.31.n in a hurry.
> 
> As regards f-l-constant-face on "foo::":  I don't really want to change
> it, since this would be a lot of work.  Changing the code in cc-fonts.el
> and the text in the manual would be relatively quick and easy, but then
> I'd have to update the regression test program 000tests.el, and
> recalcuate all the "face files" in the test suite, diff them with the
> existing versions, and commit them to the CVS repository.  There are 166
> files.face involved.  I would surely also get complaints from people
> who've got used to the existing fontification.

I don't recall any complaints back in the Emacs 19/20/21 days when it
fontified class names and namespace names as type names.  Maybe I'm being
presumptive, but I'm sure those who noticed type names and namespace names
now being fontified as constants/labels won't mind it going back to be as
type names.

> So why is f-l-constant-face so jarring here?  I can see that it's not
> particularly appropriate, but what is there about it that makes it
> repulsive and ghastly, that raises a calm competent hacker's hackles?
> (This isn't a rhetorical question.) 

I don't claim to be calm or competent, and I never said it was repulsive or
ghastly.  But, visual cues are not helpful if they are wrong, particularly
when they are something as fundamental as classes and namespaces are in C++.

The only thing that could raise my hackles is that I feel I'm just repeating
myself.  And this has been going on nearly 2 months.  I don't mind
resolution taking that long---nobody is paid to do this---it's the lack of
progress on such a simple issue that is frustrating.  But perhaps I share
some of the blaim for that.

Thanks, Simon.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Font-lock misfontifies foo::bar in C++

[Miles Bader]

"Marshall, Simon" <simon.marshall@misys.com> writes:
> The only thing that could raise my hackles is that I feel I'm just repeating
> myself.  And this has been going on nearly 2 months.  I don't mind
> resolution taking that long---nobody is paid to do this---it's the lack of
> progress on such a simple issue that is frustrating.

Well, while I agree with you that fontifying Foo:: as a type "makes more
sense" from a pedantic point of view, than fontifying as a constant, I
think most people don't really care much about such details of
fontification as long as it "looks OK" (mostly meaning important syntax
bits are visually distinctive but not annoying).

With my face setup, the current fontification looks fine, indeed I never
noticed this little inconsistency.

Now that I think about it, in fact, I rather _like_ that Foo:: is not
fontified as a type, because in a case like:

   void
   EnvmapLight::gen_samples (const Intersect &isec, SampleRayVec &samples) const

I get visually distinct faces for "void", "EnvmapLight", and
"gen_samples", which helps the readability of the code a bit I think.

-Miles
-- 
I'd rather be consing.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

RE: Font-lock misfontifies foo::bar in C++

[Marshall, Simon]

> "Marshall, Simon" <simon.marshall@misys.com> writes:
> > The only thing that could raise my hackles is that I feel I'm just 
> > repeating myself.  And this has been going on nearly 2 months.  I 
> > don't mind resolution taking that long---nobody is paid to do 
> > this---it's the lack of progress on such a simple issue that is
frustrating.
> 
> Well, while I agree with you that fontifying Foo:: as a type 
> "makes more sense" from a pedantic point of view, than 
> fontifying as a constant, I think most people don't really 
> care much about such details of fontification as long as it 
> "looks OK" (mostly meaning important syntax bits are visually 
> distinctive but not annoying).
> 
> With my face setup, the current fontification looks fine, 
> indeed I never noticed this little inconsistency.
> 
> Now that I think about it, in fact, I rather _like_ that 
> Foo:: is not fontified as a type, because in a case like:
> 
>    void
>    EnvmapLight::gen_samples (const Intersect &isec, 
> SampleRayVec &samples) const
> 
> I get visually distinct faces for "void", "EnvmapLight", and 
> "gen_samples", which helps the readability of the code a bit I think.

I don't agree with this caveat.  If something is an X, fontify it as an X
even if it is near something else that is an X.  That way, whenever you see
something that is fontified as an X, you know it's an X without having to
thing about it.  It's not about being pedantic, it's about following the
purpose of fontification.

Fontification isn't simply to use faces to de/emphasise things - it's also
there to provide visual cues to aid identification of conceptual items.
That's why we have faces with specific names (eg, font-lock-constant-face),
that are for specific concepts (eg, constants), that are applicable across a
wide range of languages, and that have particular properties (eg, are
distinct from other font-lock faces).  The preamble to font-lock.el explains
these points.  Ok, I wrote it so maybe I can't use it to bolster this point,
but the preamble does detail the rationale and list a small set of
guidelines (some of which are broken by sometimes fontifying a type, and
always fontifiying a namespace, as a constant).

But thanks for the response - sadly your's is the only one I got.

Simon.