font-lock-delimiter-face - what for?

font-lock-delimiter-face - what for?

[Dmitry Gutov]

Hi all!

What kind of delimiters this face is supposed to be used for?

Is it for string/heredoc delimiters?

If yes, how about we make it inherit from font-lock-string-face?

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

[Randy Taylor]

On Tuesday, December 27th, 2022 at 10:44, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> 
> Hi all!
> 
> What kind of delimiters this face is supposed to be used for?
> 
> Is it for string/heredoc delimiters?
> 
> If yes, how about we make it inherit from font-lock-string-face?

Hi!

It's primarily for punctuation-related ones (e.g., ‘;’, ‘:’, ‘,’), hence why it inherits from the punctuation face.

A more specific example (using c-ts-mode):
int quack = 0;
             ^ font-lock-delimiter-face

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

[Dmitry Gutov]

On 27/12/2022 18:44, Randy Taylor wrote:
> It's primarily for punctuation-related ones (e.g., ‘;’, ‘:’, ‘,’), hence why it inherits from the punctuation face.
> 
> A more specific example (using c-ts-mode):
> int quack = 0;
>               ^ font-lock-delimiter-face

All right, thank you.

Perhaps we could add some examples to the docstrings.

That could also help clarify the difference between 
font-lock-punctuation-face and font-lock-misc-punctuation-face.

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

[Eli Zaretskii]

> Date: Tue, 27 Dec 2022 17:44:23 +0200
> Cc: Randy Taylor <dev@rjt.dev>
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> Hi all!
> 
> What kind of delimiters this face is supposed to be used for?

I think if you grep the Lisp files for font-lock-delimiter-face, you
will immediately see the answer.  (I tried to make the doc string more
self-explanatory on this.)

> Is it for string/heredoc delimiters?

No, I don't think so.

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

[Randy Taylor]

On Tuesday, December 27th, 2022 at 11:54, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> On 27/12/2022 18:44, Randy Taylor wrote:
> 
> > It's primarily for punctuation-related ones (e.g., ‘;’, ‘:’, ‘,’), hence why it inherits from the punctuation face.
> > 
> > A more specific example (using c-ts-mode):
> > int quack = 0;
> > ^ font-lock-delimiter-face
> 
> 
> All right, thank you.
> 
> Perhaps we could add some examples to the docstrings.
> 
> That could also help clarify the difference between
> font-lock-punctuation-face and font-lock-misc-punctuation-face.

font-lock-punctuation-face covers all punctuation.

The rest (bracket, delimiter, misc-punctuation) are for the more specific kinds, with misc-punctuation being anything not a bracket or delimiter. For example, see bash-ts-mode which specifies $ as misc-punctuation.

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

[Dmitry Gutov]

On 27/12/2022 20:20, Randy Taylor wrote:
> font-lock-punctuation-face covers all punctuation.
> 
> The rest (bracket, delimiter, misc-punctuation) are for the more specific kinds, with misc-punctuation being anything not a bracket or delimiter. For example, see bash-ts-mode which specifies $ as misc-punctuation.

Oh... kay? So "misc punctuation" is punctuation which is not punctuation?

Just prefix characters? Anything else?

A description in text would be most welcome.

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

[Dmitry Gutov]

On 27/12/2022 19:00, Eli Zaretskii wrote:
>> Date: Tue, 27 Dec 2022 17:44:23 +0200
>> Cc: Randy Taylor <dev@rjt.dev>
>> From: Dmitry Gutov <dgutov@yandex.ru>
>>
>> Hi all!
>>
>> What kind of delimiters this face is supposed to be used for?
> 
> I think if you grep the Lisp files for font-lock-delimiter-face, you
> will immediately see the answer.  (I tried to make the doc string more
> self-explanatory on this.)

Thank you.

Without a definition, I couldn't be sure whether those uses were bugs. 
Which can be expected of experimental, new code, you know.

>> Is it for string/heredoc delimiters?
> 
> No, I don't think so.

All right.

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

[Stefan Monnier]

Dmitry Gutov [2022-12-27 21:45:33] wrote:
> On 27/12/2022 20:20, Randy Taylor wrote:
>> font-lock-punctuation-face covers all punctuation.
>> The rest (bracket, delimiter, misc-punctuation) are for the more specific
>> kinds, with misc-punctuation being anything not a bracket or
>> delimiter. For example, see bash-ts-mode which specifies $ as
>> misc-punctuation.
>
> Oh... kay? So "misc punctuation" is punctuation which is not punctuation?

IIUC `font-lock-punctuation-face` is a "parent face" for all forms of
punctuation, and then each actual punctuation is expected to use either
the delimiter, bracket, or misc face.


        Stefan

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

[Dmitry Gutov]

On 27/12/2022 23:01, Stefan Monnier wrote:
> Dmitry Gutov [2022-12-27 21:45:33] wrote:
>> On 27/12/2022 20:20, Randy Taylor wrote:
>>> font-lock-punctuation-face covers all punctuation.
>>> The rest (bracket, delimiter, misc-punctuation) are for the more specific
>>> kinds, with misc-punctuation being anything not a bracket or
>>> delimiter. For example, see bash-ts-mode which specifies $ as
>>> misc-punctuation.
>> Oh... kay? So "misc punctuation" is punctuation which is not punctuation?
> IIUC `font-lock-punctuation-face` is a "parent face" for all forms of
> punctuation, and then each actual punctuation is expected to use either
> the delimiter, bracket, or misc face.

Ah. That would make sense.

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

[Dmitry Gutov]

On 27/12/2022 23:34, Dmitry Gutov wrote:
> On 27/12/2022 23:01, Stefan Monnier wrote:
>> Dmitry Gutov [2022-12-27 21:45:33] wrote:
>>> On 27/12/2022 20:20, Randy Taylor wrote:
>>>> font-lock-punctuation-face covers all punctuation.
>>>> The rest (bracket, delimiter, misc-punctuation) are for the more 
>>>> specific
>>>> kinds, with misc-punctuation being anything not a bracket or
>>>> delimiter. For example, see bash-ts-mode which specifies $ as
>>>> misc-punctuation.
>>> Oh... kay? So "misc punctuation" is punctuation which is not 
>>> punctuation?
>> IIUC `font-lock-punctuation-face` is a "parent face" for all forms of
>> punctuation, and then each actual punctuation is expected to use either
>> the delimiter, bracket, or misc face.
> 
> Ah. That would make sense.

Maybe it would be better to remove font-lock-misc-punctuation-face, though?

People can still use font-lock-punctuation-face for everything 
punctuation-like that doesn't match the category of "brackets" or 
"delimiters".

Just like font-lock-doc-face inherits from font-lock-string-face, or 
font-lock-comment-delimiter-face inherits from font-lock-comment-face.

We don't seem to have a practice of "parent faces" which are otherwise 
unused. font-lock-punctuation-face's docstring doesn't suggest this kind 
of purpose either.

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

[Randy Taylor]

On Wednesday, December 28th, 2022 at 10:13, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> Maybe it would be better to remove font-lock-misc-punctuation-face, though?
> 
> People can still use font-lock-punctuation-face for everything
> punctuation-like that doesn't match the category of "brackets" or
> "delimiters".
> 
> Just like font-lock-doc-face inherits from font-lock-string-face, or
> font-lock-comment-delimiter-face inherits from font-lock-comment-face.
> 
> We don't seem to have a practice of "parent faces" which are otherwise
> unused. font-lock-punctuation-face's docstring doesn't suggest this kind
> of purpose either.

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

I'm indifferent either way.

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

[Dmitry Gutov]

On 28/12/2022 19:06, Randy Taylor wrote:
> On Wednesday, December 28th, 2022 at 10:13, Dmitry Gutov <dgutov@yandex.ru> wrote:
>>
>> Maybe it would be better to remove font-lock-misc-punctuation-face, though?
>>
>> People can still use font-lock-punctuation-face for everything
>> punctuation-like that doesn't match the category of "brackets" or
>> "delimiters".
>>
>> Just like font-lock-doc-face inherits from font-lock-string-face, or
>> font-lock-comment-delimiter-face inherits from font-lock-comment-face.
>>
>> We don't seem to have a practice of "parent faces" which are otherwise
>> unused. font-lock-punctuation-face's docstring doesn't suggest this kind
>> of purpose either.
> 
> 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.

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

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

[Randy Taylor]

On Wednesday, December 28th, 2022 at 13:32, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> On 28/12/2022 19:06, Randy Taylor wrote:
> 
> > On Wednesday, December 28th, 2022 at 10:13, Dmitry Gutov dgutov@yandex.ru wrote:
> > 
> > > Maybe it would be better to remove font-lock-misc-punctuation-face, though?
> > > 
> > > People can still use font-lock-punctuation-face for everything
> > > punctuation-like that doesn't match the category of "brackets" or
> > > "delimiters".
> > > 
> > > Just like font-lock-doc-face inherits from font-lock-string-face, or
> > > font-lock-comment-delimiter-face inherits from font-lock-comment-face.
> > > 
> > > We don't seem to have a practice of "parent faces" which are otherwise
> > > unused. font-lock-punctuation-face's docstring doesn't suggest this kind
> > > of purpose either.
> > 
> > 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).

> 
> > 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. What if the user just wants misc. punctuation to be different? They should all be separated IMO.

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

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.

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

[Randy Taylor]

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

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