Customizable Scope for Unicode Proofreading Rule
SDGGiesbrecht opened this issue · 2 comments
The unicode rule should allow customization to restrict it to particular scopes.
At least three levels should be recognized:
- Freeform text (documentation, comments, etc.)
- Machine identifiers (code)
- Either (string literals, etc.)
The general idea originates from @TimothyMDean’s comment in #259:
What would be really helpful for me is to have a way to exert a little more control over where this rule is applied. I understand that Workspace cannot tell the difference between string literal usage, but I can almost guarantee that my projects will almost never want this rule applied to any string literals because my use of String literals will generally not be for anything displayed to users. On the other hand, my documentation comments would absolutely be displayed as generated documentation, and so I like the idea of applying the rule there.
It would be a beginner‐level thing to implement. The parser already knows the difference between token kinds, so that part should be no more difficult than adding a new if condition. The “hardest” part would be designing a configuration API for it.
If anyone is interested in taking it on, I can give more specific directions.
Implemented in #267.
Released in Workspace 0.19.0.