VSSpellChecker
VSSpellChecker copied to clipboard
EWSoftware
Consider adding Roslyn code analyzers and/or code analysis rules for spell checking
Adding these would enable spell checking of API member names in actual source code using the extended options provided by this spell checker. It's been requested before (#15, #106, #110) and is being requested fairly often.
There are some spell checking code analysis rules provided by Microsoft but many find them to be inadequate. Adding such analyzers and rules here would probably only cover managed code languages so it still wouldn't be possible to check native code C++ or scripting languages.
Options that would differ for code analysis so would most likely needs separate settings:
- Treat underscore as separator - On by default.
- Ignore words with digits - Off by default. When off, treat digits as separators.
- Ignore words in mixed/camel case - Doesn't apply so always off.
- Detect doubled words - Probably doesn't apply much if at all but could still apply it.
- Add option to include/exclude members by visibility (public, protected, internal, private, compiler generated types/members).
This can be achieved without Roslyn, by using editor classifiers, e.g.
public static bool IsIdentifier(string name)
{
return name == "identifier" || name == "user types" || name == "class name" || name == "typescriptlexicalidentifier";
}
var classifier = = ClassifierAggregatorService.GetClassifier(buffer);
foreach (ClassificationSpan classificationSpan in classifier.GetClassificationSpans(snapshotSpan))
{
string name = classificationSpan.ClassificationType.Classification.ToLowerInvariant();
if (IsIdentifier(name))
.....
Does the classifier distinguish between API methods/properties vs variables, private vs public? If not, it's probably not something I'd want in the editor as it would be hard to limit what it spell checked. For example, I may not care about fields or private/internal members. Also, I wouldn't want it spell checking every occurrence, just on the declarations. Otherwise, there'd be too much clutter if a particular element occurred frequently.
I've been using such an implementation myself and have been enjoying it. Some people consider that misspelling are harmful in any context, private or public. As to the clutter, it is not an issue in practice. Having every occurrence flagged increases the chances that a violation is noticed, at which point "Ignore all" or "Add to dictionary" will clean all the violation with a single gesture.
What's true for you, isn't true of everyone though, and those are the ones I will hear from if I just throw in an implementation that spell checks everything without regard to the contexts noted above. Telling everyone to just use Ignore All or Add to Dictionary isn't an acceptable solution in this case. I wouldn't be happy with that response myself.
There are other considerations too such as propagating the change throughout the codebase, not just on the specific occurrence (i.e. refactoring). A simple Replace All could break a lot of stuff without proper consideration and not replacing it everywhere will also break the code. I also don't want to spell check identifiers from third-party or base framework code. Since I can't fix them, I'd rather ignore them outright instead of having to keep ignoring them or adding them to the dictionary.
Thank you for reconsidering this feature. You don't have to provide "Replace all" or even the "Replace" function at all. Just mark those misspelled API declaration names and the programmers should use the builtin Rename refactoring provided by VS to correct them.
https://github.com/aarondandy/WeCantSpell.Roslyn If you need a workaround this one is good alternative. Abandoned but still works great for me
I would just like to +1 this. We have great developers in our team, but not so great spellers. Not that they don't try, but they just don't see the spelling mistakes until they are pointed out (and English is not their first language).
@EWSoftware
Does the classifier distinguish between API methods/properties vs variables, private vs public? If not, it's probably not something I'd want in the editor as it would be hard to limit what it spell checked. For example, I may not care about fields or private/internal members. Also, I wouldn't want it spell checking every occurrence, just on the declarations.
Maybe it is possible to scan CodeElement instances (and their sub items) from dte.ActiveDocument.ProjectItem.FileCodeModel and spell check against them. You can get start points and end points of those elements and mark them if spelling mistakes are detected.
A small problem of the solution is that some specific languages, for instance, C or C++, requires some special handling and using the VCCodeElement model, otherwise some method declarations in .h files won't get checked.
You don't have to use Roslyn by the above approach and Roslyn is limited to C# and VB only.
@EWSoftware Is there any update on this? I am eagerly waiting for this feature as I am not using Resharper anymore!
Sorry, no change. I just don't have time to look into doing this right now.
@TanvirArjel While it is not a Roslyn analyzer have you checked the VS addons? Visual Studio Spell Checker provides source text spell checking. It should be a decent alternative if you are migrating away from ReSharper.
@ite-klass Could you tell me please how to enable spell checker in Visual Studio 2019?
@TanvirArjel Simply install the extension within Visual Studio -> Extensions and search for Visual Studio Spell Checker (VS2017 or later).
@ite-klass I am not talking about this. Please read the issue again and try to understand what I am talking about. I am talking about the spell checking for the identifiers like class name, method name, variable name, etc like Resharper.
Unless I close the issue with a commit that indicates it's done, it's still in the queue and nothing has changed from the last time this was asked.
Okay, better late than never but I have finally implemented a code analyzer to spell check identifiers. It's limited to C# right now but I plan on adding support for Visual Basic and perhaps F# later. It works with Visual Studio 2019 and 2022. Yes, VS2022 has a built-in spell checker now but I still think mine is better as it has more configuration options and doesn't require you to modify your OS to add dictionaries. The built-in one may get better over time and rival mine but, for now, I plan on continuing support for the extension in VS2022 and later.
There are some limitations and I'll open new work items for those for further investigation. They may be a result of my lack of knowledge when it comes to code analyzers or may not be solvable. The spell checker isn't like a normal code analyzer in some respects so what I'm trying to do just may not be possible.
Good to see that. Yes, the VS2022 spell checker does require me to modify my OS. I am using a Chinese OS and no English spell checker is installed by default.
The VS 2022 checker does not check text in the Git comment. Hopefully yours can do so.
Yes, mine still does the WPF textbox spell checking so it will check the Git comments. If it isn't currently, it may be turned off in the global options.