Re: font-lock-delimiter-face - what for?

[Dmitry Gutov]

On 29/12/2022 05:46, Randy Taylor wrote:

> > > Then we should get rid of font-lock-punctuation-face instead. If we keep it and 
> > > use it in place of misc-punctuation, then changing punctuation-face would also 
> > > change the bracket and delimiter faces, since they inherit from it.
> >
> >
> > That's usually how inheriting works, yes.
> >
> > Do we anticipate misc-punctuation to often have unique attributes? If
> > so, it might be at least some reason to keep that face.
>
> It depends on the language. A few modes already make use of it: bash-ts-mode, 
> cmake-ts-mode, and yaml-ts-mode. We should also probably use it for string 
> interpolation characters (e.g. { and }, or whatever the language uses).

They can use font-lock-punctuation-face in its place.

> > > font-lock-punctuation-face wouldn't be a great name either since it's no longer 
> > > referring to all punctuation (which is its current goal, and the docstring can 
> > > always be updated).
> >
> >
> > Why wouldn't it be referring to all punctuation? All attributes that are
> > not overridden by bracket- and delimiter- faces will show up in them.
>
> That was assuming the bracket and delimiter faces would no longer be inheriting 
> font-lock-punctuation-face. If they still are, and font-lock-punctuation-face 
> is taking the place of font-lock-misc-punctuation-face, then changing that face 
> also affects the bracket and delimiter faces too.

Yes.

> What if the user just wants misc. punctuation to be different?

Do they actually want that?

Suppose they do, though. If a user theme (user settings) or a named 
theme changes some attribute in font-lock-punctuation-face which it 
doesn't want to have in its descendants, they can go ahead and customize 
the same attribute in descendants (all 2 of them) to have a different 
value. Yes, that takes a little more effort.

Do we anticipate this to be the common case? If we have some evidence 
toward that, then sure, having a separate face makes sense. And 
font-lock-punctuation-face's docstring should mention that it's not to 
be used directly.

> If we want to get rid of font-lock-punctuation-face because we don't really do 
> that parent face stuff and/or there doesn't seem to be a use for it, then I'm 
> not against that. But I think font-lock-misc-punctuation-face should certainly 
> stay (and can be renamed if people don't like the name and have a better idea 
> for it).

No, I wanted to keep the inheritance.

Just like we have font-lock-doc-face (for docstrings) which inherits 
from font-lock-string-face, and both faces are used. Or 
font-lock-comment-delimiter-face inherits from font-lock-comment-face. 
Or font-lock-preprocessor-face inherits from font-lock-builtin-face. Etc.