It is possible to make such kind of decorations via the syntax highlight to decorate a category of syntax elements, for instance, all static members like the above, or all member declarations, which can be implemented easily and you have seen the result in my above post. However, to decorate a specific symbol, for instance, the DateTime struct or ConcurrentDictionary<,> class only, things can be much more complicated. Performance penalty will not be avoided since many symbol comparisons will occur.

There's already an existing similar implementation in Codist that I myself seldom use. If you enable the Smart Bar feature, select a symbol and click the Mark Symbol command on the Smart Bar, you can mark that symbol with one of the 9 predefined but customizable syntax styles. The decoration can be implemented into those "predefined" styles, so when you "Mark" a symbol, the above decoration can be applied to it.

Summary: It should not be very hard to implement, if we take the above implementations that we already have: Mark Symbol + Syntax Highlight, but available styles are limited to 9 (the number can be enlarged without great efforts though). What's left undone is the various decoration styles suggested in your comments (font family and style, font size, color, opacity, alignments, decoration text, etc.), the configuration module and persistence of marked symbols.

Actually I am attempting to squeeze some time to implement the #231.

from codist.

Thank you very much for this wonderful suggestion.
It is possible to render it with a text on top of the decorated text.

You may take a look at the following quick demo.

However, will the decorations be distracting?

from codist.

@fitdev
Any comment, my friend?

from codist.

That looks pretty good!

Would it also be possible to customize the font alpha (opacity) and font size?

I think this feature should be selectively applied:

• manually: the user could right click on an element to toggle the feature. Maybe it could also be an option in the Super Quick Info dialog?
• automatically: applies when an element satisfies conditional criteria. For example, if the element name matches a regex pattern, or if the element name contains a substring.

I appreciate the work you put into this extension!

from codist.

I saw this feature yesterday and wanted to comment, but decided to wait a bit. Thank you for asking :)

I do like it in general! Provided it can be:

1. Optional - that is it can be completely disabled. Or customizable - i.e. by default there will be no such "decorations", but a user can specify them in a similar fashion as can be done now for font styles and colors.
2. It should not adversely affect performance.

Ideally such decorations should be selectable from a set of predefined symbols/icons/glyphs; or can be defined by user text instead, where a user provides text, color, and maybe font style.

And in all cases position / alignment should be selectable, likely from 2 to 6 possibilities: Above/Below x Left/Center/Right.

Hopefully it won;t be too hard to implement by extending the current notion of user defined syntax highlights.

Though in terms of priorities, I would prefer an update on symbol searching / browsing first (i.e. Object-Browser like functionality with all the goodies that are currently available via context menus).

from codist.

However, to decorate a specific symbol, for instance, the DateTime struct or ConcurrentDictionary<,> class only, things can be much more complicated. Performance penalty will not be avoided since many symbol comparisons will occur.

Personally I am not interested as much in such a specific scenario.

However, for such custom styles, maybe an additional area / tab can be used to define them similar to how Comment Tagger is implemented. So, for example a specific syntax element kind (like a 'class' for example) + a user-defined RegEx = a certain user-defined style. This is just an idea about how this might be surfaced. But again, this level of customization is not really something I would be using often.

There's already an existing similar implementation in Codist that I myself seldom use. If you enable the Smart Bar feature, select a symbol and click the Mark Symbol command on the Smart Bar, you can mark that symbol with one of the 9 predefined but customizable syntax styles. The decoration can be implemented into those "predefined" styles, so when you "Mark" a symbol, the above decoration can be applied to it.

I didn't know about that. Thank you for mentioning it.

Actually I am attempting to squeeze some time to implement the #231

That's great to know!

from codist.

a specific syntax element kind (like a 'class' for example) + a user-defined RegEx = a certain user-defined style

Hmm, it was discussed in #266.

this level of customization is not really something I would be using often.

Thank you for your comment.
I have the same feeling as well.

@Decimation
Could you show some potential usage, logically, how this feature will be used, if it is implemented?

from codist.

Could you show some potential usage, logically, how this feature will be used, if it is implemented?

@wmjordan Sorry for the late response, but I would like to revisit this feature proposal. I think it would be quite useful.

As @wmjordan demonstrated here, it is possible to implement this feature. We have also briefly discussed potential behavior(s) of this feature, but not very rigorously. I will describe how this feature could be implemented, potential usages, advantages/disadvantages, etc.

Enhanced Syntax Highlighting

For clarity, this feature will be referred to as ESH (Enhanced Syntax Highlighting).

Scope

This describes how ESH would apply to certain language constructs, tokens, and other elements.
I propose #1 and/or #2.

1. Default Codist Syntax Highlighting

ESH would use the default Codist syntax highlighting engine (seen here?) and behave like other forms of syntax highlighting.

2. Type-specific Syntax Highlighting

ESH would only apply to specific types, such as DateTime. As @wmjordan described here, this would adversely affect performance. Furthermore, @fitdev (per his response) and I wouldn't be too interested in this hyper-specific level of customization.

3. Token-specific Syntax Highlighting

ESH would only apply to user-defined tokens; e.g., a variable name. This could raise the issue of maintaining a handle on the applied tokens, an issue similar to the one we discussed in #231.

4. Regex-specific Syntax Highlighting

ESH would apply to tokens matching a regex filter, as we have previously hypothesized. However, this is likely far too costly for performance.

Use-case

ESH could be used to improve readability and disambiguate language constructs. Here are some examples:

Example 1

Suppose a user wants to customize keyword tokens, however there are different subtypes of keyword tokens. However, the user doesn't want to customize other syntax elements because: 1), he wants to preserve unique customizations for use with other elements; and/or 2), he can't change the other elements of syntax customization due to precedence or other overrides.

Example ESH Configuration GUI

Current GUI:

Hypothetical ESH view:

Note: this GUI mockup doesn't include options for positioning the glyph

from codist.

Any thoughts @wmjordan @fitdev?

from codist.

Seems reasonable. Ability to control placement (position) would be nice though.

from codist.

I have little idea about what to display on top of those "highlighted" elements.

I tried to implement a demo and found that there were too many decorations which distracted me.

from codist.