Crates.io | typos-dict |
lib.rs | typos-dict |
version | |
source | src |
created_at | 2019-10-25 15:53:29.828404 |
updated_at | 2024-12-12 20:48:57.38054 |
description | Source Code Spelling Correction |
homepage | |
repository | https://github.com/crate-ci/typos |
max_upload_size | |
id | 175642 |
Cargo.toml error: | TOML parse error at line 28, column 1 | 28 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
size | 0 |
Source code spell checker
Finds and corrects spelling mistakes among source code:
Dual-licensed under MIT or Apache 2.0
Download a pre-built binary (installable via gh-install).
Or use rust to install:
$ cargo install typos-cli
Or use Homebrew to install:
$ brew install typos-cli
Or use Conda to install:
$ conda install typos
Or use Pacman to install:
sudo pacman -S typos
Most commonly, you'll either want to see what typos are available with
$ typos
Or have them fixed
$ typos --write-changes
$ typos -w
If there is any ambiguity (multiple possible corrections), typos
will just report it to the user and move on.
Sometimes, what looks like a typo is intentional, like with people's names, acronyms, or localized content.
To mark a word or an identifier (grouping of words) as valid, add it your _typos.toml
by declaring itself as the valid spelling:
[default]
extend-ignore-identifiers-re = [
# *sigh* this just isn't worth the cost of fixing
"AttributeID.*Supress.*",
]
[default.extend-identifiers]
# *sigh* this just isn't worth the cost of fixing
AttributeIDSupressMenu = "AttributeIDSupressMenu"
[default.extend-words]
# Don't correct the surname "Teh"
teh = "teh"
For cases like localized content, you can disable spell checking of file contents while still checking the file name:
[type.po]
extend-glob = ["*.po"]
check-file = false
(run typos --type-list
to see configured file types)
If you need some more flexibility, you can completely exclude some files from consideration:
[files]
extend-exclude = ["localized/*.po"]
typos
provides several building blocks for custom native integrations
-
reads from stdin
, --write-changes
will be written to stdout
--diff
to provide a diff--format json
to get jsonlines with exit code 0 on no errors, code 2 on typos, anything else is an error.Examples:
$ # Read file from stdin, write corrected version to stdout
$ typos - --write-changes
$ # Creates a diff of what would change
$ typos dir/file --diff
$ # Fully programmatic control
$ typos dir/file --format json
You can see what the effective config looks like by running
$ typos --dump-config -
You can then see how typos is processing your project with
$ typos --files
$ typos --identifiers
$ typos --words
If you need to dig in more, you can enable debug logging with -v
Does the file show up in typos --files
?
If not, check your config with typos --dump-config -
.
The [files]
table controls how we walk files.
If you are using files.extend-exclude
,
are you running into #593?
If you are using files.ignore-vcs = true
,
is the file in your .gitignore
but git tracks it anyways?
Prefer allowing the file explicitly (see #909).
Does the identifier show up in typos --identifiers
or the word show up in typos --words
?
If not, it might be subject to one of typos' heuristics for
detecting non-words (like hashes) or
unambiguous words (like words after a \
escape).
If it is showing up, likely typos
doesn't know about it yet.
typos
maintains a list of known typo corrections to keep the false positive
count low so it can safely run unassisted.
This is in contrast to most spell checking UIs people use where there is a known list of valid words. In this case, the spell checker tries to guess your intent by finding the closest-looking word. It then has a gauge for when a word isn't close enough and assumes you know best. The user has the opportunity to verify these corrections and explicitly allow or reject them.
For more on the trade offs of these approaches, see Design.