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

[Dmitry Gutov <dgutov@yandex.ru>]

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.