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

[Randy Taylor <dev@rjt.dev>]

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).

Whether or not we want font-lock-punctuation-face as the parent face of all of them (or get rid of it entirely) I don't know. I'm not sure how likely it will be to customize all punctuation as opposed to specific kinds, but I reckon it will probably be quite rare. We can always add it back in later if we're wrong. Or just leave it all as is (and we can certainly improve its docstring).