Bypass hashing when we know (through str::len) that a word won't be in
the dict.
Master:
```
real 0m26.675s
user 0m33.683s
sys 0m4.535s
```
With this change
```
real 0m24.432s
user 0m32.492s
sys 0m4.190s
```
Bypass hashing when we know (through str::len) that a word won't be in
the dict.
Master:
```
real 0m26.675s
user 0m33.683s
sys 0m4.535s
```
With this change:
```
real 0m24.060s
user 0m31.559s
sys 0m4.258s
```
`HashMap::get` (at least hashbrown) hashes before getting and doesn't
check if dict is empty. For the custom dict, a common use case will
have the dict be empty.
Master:
```
real 0m26.675s
user 0m33.683s
sys 0m4.535s
```
Bypassing `HashMap::get`
```
real 0m16.415s
user 0m14.519s
sys 0m4.118s
```
On a moderately sized repo.
If we have to hash for the custom dict, we might as well be fast about
it. We do not need a cryptographically secure algorithm since the
content is fixed for the user.
Master:
```
real 0m26.675s
user 0m33.683s
sys 0m4.535s
```
With ahash:
```
real 0m23.993s
user 0m30.800s
sys 0m4.440s
```
This reverts commit 0052617fcd.
The fix for #134 was backwards. It turns out `overrides` is for
including rather than ignoring. Will need to look at this further.
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.
THis is to help with cases like a monorepo with vendored dependencies.
A user might want to search (`.ignore`) them but not hold the code to
the same standards as first-party code.
Fixes#134
The goal is to be as accepting and unobtrusive to new code bases as
possible. To this end, we correct typos into the closest english
dialect.
If someone wants to opt-in, they can have typos correct to a specific
english dialect.
Fixes#52Fixes#22
