Skip to content

Conversation

@DimitriPapadopoulos
Copy link
Collaborator

Typo matching is case insensitive, it doesn't make sense to use uppercase in this context.

While we would like a mechanism to suggest that "manuel" is a typo but "Manuel" is not, writing the typo as "Manuel" doesn't help in any way.

We keep uppercase in suggested fixes, that could be useful some day.

See also #1578 (comment).

@DimitriPapadopoulos
Copy link
Collaborator Author

@larsoner or @peternewman Could you have a look?

This does create a backwards compatibility issue: some modified typos may appear in existing lists of words to ignore, using the former capitalisation of the first letter. However, I feel it is worth the pain.

@larsoner
Copy link
Member

larsoner commented Jun 2, 2024

I feel it is worth the pain.

Indeed this is likely to cause problems for people.

What is the gain here exactly? If it's just logical and cleaner but doesn't help end users, I'm not sure it's worth inflicting the pain.

@DimitriPapadopoulos
Copy link
Collaborator Author

The gain is that the case of -L arguments would be simpler to explain: "all lowercase" instead of "the case used in the dictionary the word is in". I had left such a documentation change for later.

@larsoner
Copy link
Member

larsoner commented Jun 2, 2024

One backward compatible way to accomplish this would be to check if the ignore matches the upper or lower cased version

Typo matching is case insensitive, it doesn't make sense to use
uppercase in this context.

While we would like a mechanism to suggest that "manuel" is a typo but
"Manuel" is not, writing the typo as "Manuel" doesn't help in any way.

We keep uppercase in suggested fixes, that could be useful some day.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants