[Feature] different highlight style defs for tag and text #72
Unanswered
Sorontik
asked this question in
Potential behavior-altering enhancement
Replies: 1 comment
-
|
Would like to gather feedback from the community before doing that! Let's start a discussion here! 😊 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
For me, it would be really useful, if i could specify different highlighting styles for the tag and the text behind it.
I like my tags to really stand out and serve as an eye-catcher and visual anchor, so i like to style them with a bright background and then choose the foreground color for contrast and readability.
extending this to the text behind the tag makes the entire line very bulky and irritating, so i don't want to use the "type"-options that include the text or the whole line - but i would still like to have a visual connection between the text and the tag by setting the foreground color of the text to a related (but readable) color.
To achieve this, it would be nice if i could specify two sets of font-related style options in the default- or custom highlights:
one for the tag and one for the text behind it.
This could be further generalized into a replacement of the type-option and allow for even more versatility by defining a set of up to 7 style-blocks:
if a definition is missing, the corresponding content would retain it's original editor formatting (syntax-highlighting etc.)
It would probably also be useful, if one block could reference another block so that any option that is not defined in the block itself is taken from the referenced block before falling back to the default highlight definition. This would help avoid a lot of duplicate definitions if some of the blocks are supposed to look identical.
The icing on the cake would be detail-configuration options that allow to specify if e.g. the
code-style should also be applied to whitespace between the last code-char and the comment char or if this whitespace should retain the default editor formatting, and the same option for the whitespace between the comment char and tag (and tag and sub-tag).Well, that escalated into a rather large suggestion, but i think it would add a tremendous amount of versatility and significantly improve the value of this extension.
Beta Was this translation helpful? Give feedback.
All reactions