Open Decimation opened 12 months ago
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?
@fitdev Any comment, my friend?
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:
I appreciate the work you put into this extension!
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:
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).
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.
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!
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?
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.
For clarity, this feature will be referred to as ESH (Enhanced Syntax Highlighting).
This describes how ESH would apply to certain language constructs, tokens, and other elements.
I propose #1
and/or #2
.
ESH would use the default Codist syntax highlighting engine (seen here?) and behave like other forms of 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.
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.
ESH would apply to tokens matching a regex filter, as we have previously hypothesized. However, this is likely far too costly for performance.
ESH could be used to improve readability and disambiguate language constructs. Here are some examples:
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.
Current GUI:
Hypothetical ESH view:
Note: this GUI mockup doesn't include options for positioning the glyph
Any thoughts @wmjordan @fitdev?
Seems reasonable. Ability to control placement (position) would be nice though.
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.
Proposal
Add the ability to decorate a syntax element with special glyphs. These glyphs could be:
Example
Here is a rough example.
Red bounding box shows the boundaries within which the glyph can be placed.
The user would choose where the glyph is placed (e.g., top left, top center, ...) relative to the center of the syntax element.
Example 1
glyph is
★
placed top rightExample 2
glyph is
🔅
placed top left