* font-lock-delimiter-face - what for? @ 2022-12-27 15:44 Dmitry Gutov 2022-12-27 16:44 ` Randy Taylor 2022-12-27 17:00 ` Eli Zaretskii 0 siblings, 2 replies; 16+ messages in thread From: Dmitry Gutov @ 2022-12-27 15:44 UTC (permalink / raw) To: emacs-devel; +Cc: Randy Taylor 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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: font-lock-delimiter-face - what for? 2022-12-27 15:44 font-lock-delimiter-face - what for? Dmitry Gutov @ 2022-12-27 16:44 ` Randy Taylor 2022-12-27 16:54 ` Dmitry Gutov 2022-12-27 17:00 ` Eli Zaretskii 1 sibling, 1 reply; 16+ messages in thread From: Randy Taylor @ 2022-12-27 16:44 UTC (permalink / raw) To: Dmitry Gutov; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: font-lock-delimiter-face - what for? 2022-12-27 16:44 ` Randy Taylor @ 2022-12-27 16:54 ` Dmitry Gutov 2022-12-27 18:20 ` Randy Taylor 0 siblings, 1 reply; 16+ messages in thread From: Dmitry Gutov @ 2022-12-27 16:54 UTC (permalink / raw) To: Randy Taylor; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: font-lock-delimiter-face - what for? 2022-12-27 16:54 ` Dmitry Gutov @ 2022-12-27 18:20 ` Randy Taylor 2022-12-27 19:45 ` Dmitry Gutov 0 siblings, 1 reply; 16+ messages in thread From: Randy Taylor @ 2022-12-27 18:20 UTC (permalink / raw) To: Dmitry Gutov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: font-lock-delimiter-face - what for? 2022-12-27 18:20 ` Randy Taylor @ 2022-12-27 19:45 ` Dmitry Gutov 2022-12-27 21:01 ` Stefan Monnier 0 siblings, 1 reply; 16+ messages in thread From: Dmitry Gutov @ 2022-12-27 19:45 UTC (permalink / raw) To: Randy Taylor; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: font-lock-delimiter-face - what for? 2022-12-27 19:45 ` Dmitry Gutov @ 2022-12-27 21:01 ` Stefan Monnier 2022-12-27 21:34 ` Dmitry Gutov 0 siblings, 1 reply; 16+ messages in thread From: Stefan Monnier @ 2022-12-27 21:01 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Randy Taylor, emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: font-lock-delimiter-face - what for? 2022-12-27 21:01 ` Stefan Monnier @ 2022-12-27 21:34 ` Dmitry Gutov 2022-12-28 15:13 ` Dmitry Gutov 0 siblings, 1 reply; 16+ messages in thread From: Dmitry Gutov @ 2022-12-27 21:34 UTC (permalink / raw) To: Stefan Monnier; +Cc: Randy Taylor, emacs-devel 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: font-lock-delimiter-face - what for? 2022-12-27 21:34 ` Dmitry Gutov @ 2022-12-28 15:13 ` Dmitry Gutov 2022-12-28 17:06 ` Randy Taylor 0 siblings, 1 reply; 16+ messages in thread From: Dmitry Gutov @ 2022-12-28 15:13 UTC (permalink / raw) To: Stefan Monnier; +Cc: Randy Taylor, emacs-devel 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: font-lock-delimiter-face - what for? 2022-12-28 15:13 ` Dmitry Gutov @ 2022-12-28 17:06 ` Randy Taylor 2022-12-28 18:32 ` Dmitry Gutov 0 siblings, 1 reply; 16+ messages in thread From: Randy Taylor @ 2022-12-28 17:06 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Stefan Monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: font-lock-delimiter-face - what for? 2022-12-28 17:06 ` Randy Taylor @ 2022-12-28 18:32 ` Dmitry Gutov 2022-12-29 3:46 ` Randy Taylor 0 siblings, 1 reply; 16+ messages in thread From: Dmitry Gutov @ 2022-12-28 18:32 UTC (permalink / raw) To: Randy Taylor; +Cc: Stefan Monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: font-lock-delimiter-face - what for? 2022-12-28 18:32 ` Dmitry Gutov @ 2022-12-29 3:46 ` Randy Taylor 2022-12-29 15:57 ` Dmitry Gutov 0 siblings, 1 reply; 16+ messages in thread From: Randy Taylor @ 2022-12-29 3:46 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Stefan Monnier, emacs-devel 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). ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: font-lock-delimiter-face - what for? 2022-12-29 3:46 ` Randy Taylor @ 2022-12-29 15:57 ` Dmitry Gutov 2022-12-29 18:41 ` Randy Taylor 0 siblings, 1 reply; 16+ messages in thread From: Dmitry Gutov @ 2022-12-29 15:57 UTC (permalink / raw) To: Randy Taylor; +Cc: Stefan Monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: font-lock-delimiter-face - what for? 2022-12-29 15:57 ` Dmitry Gutov @ 2022-12-29 18:41 ` Randy Taylor 2022-12-30 4:59 ` Yuan Fu 0 siblings, 1 reply; 16+ messages in thread From: Randy Taylor @ 2022-12-29 18:41 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Stefan Monnier, emacs-devel 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). ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: font-lock-delimiter-face - what for? 2022-12-29 18:41 ` Randy Taylor @ 2022-12-30 4:59 ` Yuan Fu 0 siblings, 0 replies; 16+ messages in thread From: Yuan Fu @ 2022-12-30 4:59 UTC (permalink / raw) To: Randy Taylor; +Cc: Dmitry Gutov, Stefan Monnier, emacs-devel > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: font-lock-delimiter-face - what for? 2022-12-27 15:44 font-lock-delimiter-face - what for? Dmitry Gutov 2022-12-27 16:44 ` Randy Taylor @ 2022-12-27 17:00 ` Eli Zaretskii 2022-12-27 19:46 ` Dmitry Gutov 1 sibling, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2022-12-27 17:00 UTC (permalink / raw) To: Dmitry Gutov; +Cc: emacs-devel, dev > 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: font-lock-delimiter-face - what for? 2022-12-27 17:00 ` Eli Zaretskii @ 2022-12-27 19:46 ` Dmitry Gutov 0 siblings, 0 replies; 16+ messages in thread From: Dmitry Gutov @ 2022-12-27 19:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel, dev 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2022-12-30 4:59 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-12-27 15:44 font-lock-delimiter-face - what for? Dmitry Gutov 2022-12-27 16:44 ` Randy Taylor 2022-12-27 16:54 ` Dmitry Gutov 2022-12-27 18:20 ` Randy Taylor 2022-12-27 19:45 ` Dmitry Gutov 2022-12-27 21:01 ` Stefan Monnier 2022-12-27 21:34 ` Dmitry Gutov 2022-12-28 15:13 ` Dmitry Gutov 2022-12-28 17:06 ` Randy Taylor 2022-12-28 18:32 ` Dmitry Gutov 2022-12-29 3:46 ` Randy Taylor 2022-12-29 15:57 ` Dmitry Gutov 2022-12-29 18:41 ` Randy Taylor 2022-12-30 4:59 ` Yuan Fu 2022-12-27 17:00 ` Eli Zaretskii 2022-12-27 19:46 ` Dmitry Gutov
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).