Case sensitive (case only) corrections

[scop]

It seems on surface (admittedly not much homework done on my part) that typos does not support case only corrections. If that's the case, here's an RFE to support that :)

Some examples off the top of my head with which this would be useful:

• ZigBee -> Zigbee
• SystemD -> systemd
• Day of week, month, etc names spelled in lowercase that should start with a capital letter (dunno if this would be more problematic than the above examples that are easy to recognize)

[epage]

Day of week, month, etc names spelled in lowercase that should start with a capital letter (dunno if this would be more problematic than the above examples that are easy to recognize)

The focus of typos is on source code, so we view days of week as either snake_case or CamelCase. We don't have the information (and getting the information is out of scope) for us to know when one case is preferred over another.

ZigBee -> Zigbee
SystemD -> systemd

If this is for case outside of variables, then see above.

If this is for how these should be cased in variables, this is the inverse of #795 where we need to take two words within an identifier and merge them into one word. This is a lot more doable than #795 as we already know what case is involved. We'd just have to deal with scanning identifiers for these words and figuring out precedence rules (e.g. but what "system" is the end of one word join and the start of another word join).

[scop]

Hmm, I've always thought that the focus/scope of source code would include comments, docstrings, error message strings etc. Granted, I guess that'd mean a general purpose checker with some specific source code capabilities on variable and function names etc.

Anyway, FWIW, to me, variable and function names and such are a much less interesting area than things written specifically/only for humans to read, such as the ones mentioned above. Maybe typos is not the best possible match for this use case.

[epage]

My original motivating case was dealing with a typo in an API for a decade.

However, that doesn't mean this is exclusively for those cases. I have this run on code based with documentation or only documentation-only documents (RFCs). To meet our needs for generality and performance, its difficult to handle comments / documentation and knowing when the words in comments/documentation are regular language vs references to identifiers in the code.