Skip to content

[Feature] different highlight style defs for tag and text #70

@Sorontik

Description

@Sorontik

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:

  • indentation (whitespace at the beginning)
  • code (text before the comment-characters)
  • comment (the comment characters)
  • tag
  • sub-tag
  • text (all text after the tags/sub-tags)
  • post-line (empty screen space from the last text char to the full editor width)

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.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions