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

Custom dictionaries #9

Closed
epage opened this issue Jun 18, 2019 · 3 comments · Fixed by #144
Closed

Custom dictionaries #9

epage opened this issue Jun 18, 2019 · 3 comments · Fixed by #144
Labels
enhancement Improve the expected
Milestone

Comments

@epage
Copy link
Collaborator

epage commented Jun 18, 2019

Source

  • passed in on cli
  • found on disc

Include

  • file type definitions
  • per file type corrections
@epage epage added the enhancement Improve the expected label Jun 26, 2019
@epage epage added this to the 0.2 milestone Oct 29, 2019
epage referenced this issue in epage/typos Sep 3, 2020
Sometimes you just have to live with a typo or its done intentionally
(like weird company names).  With this commit, a user can now identifier
blessed identifiers and words.

This is ostly what is needed for #9 but sometimes people will have
common typos that they'll want to provide corrections for.
epage referenced this issue in epage/typos Sep 3, 2020
Sometimes you just have to live with a typo or its done intentionally
(like weird company names).  With this commit, a user can now identifier
blessed identifiers and words.

This is ostly what is needed for #9 but sometimes people will have
common typos that they'll want to provide corrections for.
@epage
Copy link
Collaborator Author

epage commented Sep 12, 2020

I realized there are three pieces of information a user may want to specify

  • Always valid words
  • Always invalid words
  • Correctable words

I suspect it might get cumbersome to have 3 custom entries x 2 types of words.

What if the user specifies it as

[default.dictionary]
invalid=""
valid="valid"
correcton="correction"

ie

  • Invalid have no correct form
  • Valid are their own correct form

We could then implement this as

enum Correction {
    Invalid,
    Valid,
    Correction(str)
}

epage referenced this issue in epage/typos Oct 27, 2020
Switching `valid-*` to just `*` where you map typo to correction, with
support for always-valid and never-valid.

Fixes #9
epage referenced this issue in epage/typos Oct 27, 2020
Switching `valid-*` to just `*` where you map typo to correction, with
support for always-valid and never-valid.

Fixes #9
epage referenced this issue in epage/typos Oct 27, 2020
Switching `valid-*` to just `*` where you map typo to correction, with
support for always-valid and never-valid.

Fixes #9
epage referenced this issue in epage/typos Oct 28, 2020
Switching `valid-*` to just `*` where you map typo to correction, with
support for always-valid and never-valid.

Fixes #9
epage referenced this issue in epage/typos Oct 28, 2020
Switching `valid-*` to just `*` where you map typo to correction, with
support for always-valid and never-valid.

Fixes #9
@zillionare
Copy link

how to use this feature? typos always get wrong when parse numpy.typing.NDArray, and it'll always modify it as ANDArray.

@epage
Copy link
Collaborator Author

epage commented Aug 30, 2022

Have you checked out our documentation on false positives?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improve the expected
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants