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

[Yuan Fu]

> On Dec 29, 2022, at 10:41 AM, Randy Taylor <dev@rjt.dev> wrote:
> 
> On Thursday, December 29th, 2022 at 10:57, Dmitry Gutov <dgutov@yandex.ru> 
> wrote:
>> 
>> 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.
> 
> I don't know about common but there's certainly a use case. I would say even 
> more so for misc-punctuation than the others because special symbols can fall 
> into that category.
> 
> To me it doesn't make sense to have font-lock-punctuation-face be inherited 
> by bracket and delimiter and also be used for misc. punctuation purposes. 
> Misc. punctuation is a distinctly separate category IMO (especially since it 
> has a corresponding tree-sitter feature for syntax highlighting). I added 
> font-lock-punctuation-face primarily to control all of the different kinds of 
> punctuation (same as what the previous Emacs tree-sitter dynamic module did).

I tend to think of the inheritance in font-lock faces as a convenient 
placeholder more than actual inheritance. Ie, if a theme/user doesn’t bother to 
set separate values for every font-lock face, some faces simply use other 
face’s value. This is especially true for new font-lock faces, since themes and 
users don’t need to update their config.

Yuan