Skip to content
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

Support corrections containing spaces #795

Open
not-my-profile opened this issue Aug 7, 2023 · 3 comments
Open

Support corrections containing spaces #795

not-my-profile opened this issue Aug 7, 2023 · 3 comments
Labels
question Uncertainty is involved

Comments

@not-my-profile
Copy link
Contributor

not-my-profile commented Aug 7, 2023

The codespell dictionary contains corrections such as the following:

abouta->about a, about,
shouldbe->should, should be,

It would be nice if typos could also support them. The challenge with that of course is that we also check for typos within snake_case and camelCase.

See also #400

@epage epage added the enhancement Improve the expected label Aug 8, 2023
@epage epage added question Uncertainty is involved and removed enhancement Improve the expected labels Dec 13, 2023
@epage
Copy link
Collaborator

epage commented Dec 13, 2023

The challenge is knowing what case should be used when doing word-joining (or if word joining should even be used)

@jrosdahl
Copy link

jrosdahl commented Jan 5, 2024

The challenge is knowing what case should be used when doing word-joining (or if word joining should even be used)

Is the problem what to do when using -w/--write-changes, e.g. whether atleast should be at least or at_least (or something else)? If so, would it be an option to simply not offer an automated correction, similar to cases where there are several possible one-word corrections?

@epage
Copy link
Collaborator

epage commented Jun 23, 2024

Is the problem what to do when using -w/--write-changes, e.g. whether atleast should be at least or at_least (or something else)? If so, would it be an option to simply not offer an automated correction, similar to cases where there are several possible one-word correcti

In part. This also gets into how we pass around the correction and then render it. We'd need to make it clear to the reader that they shouldn't literally do what we say. I would think its obvious but I've run into too many devs who blindly do things to resolve a message from a tool, like committing files reported by git status that they have no clue what it is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Uncertainty is involved
Projects
None yet
Development

No branches or pull requests

3 participants