Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Community Toolkit MVVM Attributes #266

Open
HeinzKessler opened this issue May 18, 2023 · 18 comments
Open

Support Community Toolkit MVVM Attributes #266

HeinzKessler opened this issue May 18, 2023 · 18 comments
Labels
>_<! under consideration of dropping... enhancement Highlight Syntax highlight

Comments

@HeinzKessler
Copy link

The .Net Community Toolkit is sure to become popular very quickly.
Its MVVM toolkit allows for automatic generation of boilerplate code needed for properties, relay commands etc. in WPF.

A WPF "observable property" will look like this:

[ObservableProperty]
private bool _myPropertyValue;

The actual property will be auto generated in a second .cs file, and the class has to be a partial class.
See here.
Therefore the lines above act like a public property.

The only drawback is that there's only a private field left, decorated with the [ObservableProperty] attribute, which will not be formatted as a public property by Codist. Therefore it would be nice if codist could recognize the code generation attributes of the .Net Community Toolkit and offer syntax highlighting accordingly.

@wmjordan
Copy link
Owner

recognize the code generation attributes of the .Net Community Toolkit and offer syntax highlighting accordingly.

I am afraid this will slow down the syntax highlighter a bit.
When highlighting a field, Codist will first recognize that it is a IFieldSymbol, then if this request is supported, it will iterate through all custom attributes and compare them each other and check if it is of type communitytoolkit.mvvm.componentmodel.ObservablePropertyAttribute, by comparing the custom attribute name first, then each namespace part one by one and try to find out the corresponding property and make sure it is public.
The current implementation only deal with properties exposed by IFieldSymbol and the new implementation will have to take care for custom attributes. All instances of fields will be checked like that, which is a draw back to performance.

However, on Super Quick Info and the symbol tool tip for those annotated fields, you can read the [ObservableProperty] annotation. If you are not sure about a field, you can just hover your mouse on it and get the information.

@HeinzKessler
Copy link
Author

Thanks for this comprehensive explanation. I suppose, 99% of the fields won't have any custom attributes at all, so the performance overhead will mostly come down to the attribute check only. But OK, at least this will remain and will affect performance.
Is there an existing way to format such fields "manually", e.g. by using certain prefixes or postfixes in the name, i.e. is there a way to format fields by some kind of regex pattern? Or some other trick to format them manually?

@wmjordan
Copy link
Owner

wmjordan commented May 30, 2023

is there a way to format fields by some kind of regex pattern? Or some other trick to format them manually?

Yes. Theoretically it is not difficult to implement at all. However, the logic will affect ALL symbols being highlighted.
The current workflow to highlight C# symbols:

  1. VS passes some text (typically a line) to the tagger (the class which highlights text)
  2. the tagger calls Roslyn to parse the document (or fetch the semantic model of the already parsed and cached document)
  3. tagger analyzes each token, finds out the syntax node it belongs to, and the possible code symbol
  4. tagger checks the symbol kind (class, struct, field, property, etc.), then the more concrete semantic aspect, for instance, static, virtual, volatile, etc. For each found out semantic aspect, generate a tagged span (the span of the token with the classification tag) and yield return to the tag aggregator.
  5. the consumer of the tag aggregator will use the span and tag to highlight the code.
  6. VS repeats the above steps to highlight other parts of the code

If "regex pattern enabled" highlight is to be implemented, for instance, you may want only private instance fields with a prefix "_m_" to be tagged with "My Style 1", but someone else will prefer that any private static fields start with "__" to be highlighted with "His Style 1", and someone else will prefer that any method named with a suffix "Async" to be highlighted with "Her Style 1", but private method suffixed with "Async" should be "Her Style 2"...

The code logic will become complicated. The current implementation in the step 4 does not have associated concept for compound sematic aspects such as "private static", "sealed override", etc. It once met with a member or type which is "private", it yields a "C#: Private member" tag, and when it later finds that member or type is "static", it yields another "C#: Static member" tag. So, if private instance fields with a prefix "m" to be tagged with "My Style 1" is to be implemented, we have to rewrite the logic of the tagger to compare with compound aspects.

If the "Regex pattern enabled" highlight does not cooperate with the aforementioned sematic aspects, the code logic will be much simpler. However, each token will be examined by the regular expressions, which may be a little slow, I am afraid.

@wmjordan wmjordan added enhancement >_<! under consideration of dropping... labels Jun 29, 2023
@wmjordan wmjordan added the Highlight Syntax highlight label Sep 16, 2024
@wmjordan
Copy link
Owner

Is there an existing way to format such fields "manually", e.g. by using certain prefixes or postfixes in the name, i.e. is there a way to format fields by some kind of regex pattern?

The next version will allow you to do this by specifying regular expressions with matched tags.

@wmjordan
Copy link
Owner

Hi,

I've just uploaded a new beta version which allows you define regular expressions to highlight your code.

The detail of the mechanism can be read in the Wiki page here: https://github.com/wmjordan/Codist/wiki/ClassificationTypes.json-and-Codist.ct.json

@wmjordan
Copy link
Owner

The new feature is not yet complete. For instance, the custom rules only apply to files in the same directory of the configuration file. Please take some time to read the Wiki and give the new version a try. Your feedback is also welcome.

@HeinzKessler
Copy link
Author

HeinzKessler commented Sep 26, 2024 via email

@wmjordan
Copy link
Owner

The new beta can be downloaded here. It is an issue that pinned on top of the Issues section.

@HeinzKessler
Copy link
Author

HeinzKessler commented Sep 26, 2024 via email

@wmjordan
Copy link
Owner

Just leave a line here on GitHub will do.
Thank you for taking time to test the feature.

@HeinzKessler
Copy link
Author

The documentation says, a ClassificationTypes.json file should be created in Codist's configuration folder, but I didn't find an information where this folder is.
Aas a proposal, in the Codist configuration window, under "Customized", maybe you want to make the words "config folder" a link to just this folder.

@wmjordan
Copy link
Owner

You are right.

Maybe it is appropriate to offer a link to create a template file in the config folder, and a button to open that config file with Visual Studio.

@HeinzKessler
Copy link
Author

Can you tell me where I can find that folder?

@wmjordan
Copy link
Owner

Click the Tools/Options menu command, find Codist.
In the middle of the interface, click the "Open Config Folder" button.
image

@HeinzKessler
Copy link
Author

Thanks.
The documentation says that "Advanced Syntax Highlighting" shall be enabled in order to benefit from the regular expressions in Codist.ct.json but I found no place to enable Advanced Syntax Highlighting.
I feel a little stupid now... :-)

@wmjordan
Copy link
Owner

Sorry to have you confused.

Please take a look at the above screenshot, the Advanced Syntax Highlight is the first checkbox under the "Feature Controllers".

@HeinzKessler
Copy link
Author

Oh, thanks! Then maybe you should call it what it is: "Advanced Syntax Highlight"

@wmjordan
Copy link
Owner

Thanks for your valuable feedback.
I recently modified the WiKi page.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>_<! under consideration of dropping... enhancement Highlight Syntax highlight
Projects
None yet
Development

No branches or pull requests

2 participants