-
Notifications
You must be signed in to change notification settings - Fork 465
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
CamelCase support? #196
Comments
This would be amazing but I'm worried it would report a ton of false positives. |
Maybe a switch would help avoid that? |
I have implemented this feature locally a few weeks ago and had no problems with false positives. I think at some point we have to discuss how important the write-changes option is and how it influences new features like support for CamelCase, c-escapes or customized regular expressions to split the words. Since I use codespell only for reporting misspellings (it runs on every compile of my projects) I do not care much about this option. Thoughts? |
It would be fine with me to say that only a subset of corrections can be automatically applied, so long as the others were still reported. For example adding a feature for within-CamelCase spelling errors, it seems reasonable to specify in the docs that these can be reported but not (at the moment) automatically corrected. |
I agree with @larsoner |
See also discussion in #314 . |
@thdot where is your CamelCase read-only checking code? I'd love to get it merged in! |
An example regex to extract individual words from camelCase and mixedACRONYMSpelling that may be useful (PCRE, though) This was from a project to check spelling and be aware of PHP's syntax (e.g. single-quoted strings) https://github.com/TysonAndre/PhanTypoCheck/blob/0.0.3/src/TypoCheckUtils.php#L100-L102 |
I'd just like to add that my initial solution had quadratic performance for long strings of lowercase letters, and should not be used as-is. (it didn't specify a start boundary)
|
Thought I might note that we use codespell in our CI for github.com/rook/rook, and we have a function |
I just want to mention that I would be perfectly happy with detection only quadratic camel case support (I found |
I mean the one that I posted fixed the quadratic runtime I had with my first attempt, so maintainers should avoid introducing similar bugs in however they solve it. The buggy one was The fixed one was |
Is it possible to treat camel case class names etc. as separate words, so that spelling errors could be found?
The text was updated successfully, but these errors were encountered: