crate-ci / typos Goto Github PK

Some hex numbers might appear as words and those words might look like typos. We should do like scspell and ignore them.

For large projects, it can be helpful to support layered configs.

These would exist for helping to debug configurations

Right now we proactively parse out lines and then parse within a line. What if instead we found out our line number by counting the new lines afterwards? This puts the cost on the typo case, which should be rare, rather than on every case when parsing

See https://github.com/myint/scspell/blob/master/scspell/__init__.py#L363 for how scspell does it.

See https://travis-ci.org/epage/defenestrate/jobs/550805412

I'm thinking this should be one of the programmatic messages sent to stdout rather than using a logging crate.

Currently we load the entire file in memory and search for a null byte through all of it.

See #29 for other implementations for how to speed it up

Seems like some people might like this as an optional feature

See https://github.com/LDNOOBW/List-of-Dirty-Naughty-Obscene-and-Otherwise-Bad-Words

split_ident allocates into a Vec rather than lazily returning values as an iterator.

See https://docs.rs/exit-code/1.0.0/exit_code/

Including broken pipe

Codes of interest

• USAGE_ERROR
• CONFIG_ERROR
• FAILURE for runtime errors?
• DATA_ERROR for typos?

Source

• passed in on cli
• found on disc

Include

• file type definitions
• per file type corrections

Scspell will parse the file assumng escape characters exist but let you opt out.
See https://github.com/myint/scspell/blob/master/scspell/__init__.py#L78

Escape character support could instead be a file type setting, like dictionary values

KStringCow has the following states:

• Box<str>
• 'static str
• 's str
• inlined string

If we add a From to it, we can possibly detect being able to use the inline string and write straight to it, avoiding the allocation when case correcting.

In addition, we'd be dropping from 4 machine words to 3 machine words iirc.

This would be relatively easy while improving the scannability of the results.

At least this is how ripgrep does it.

We'll to define file types and what traits those file types should have (specialized dictionaries, _ / - as identifier characters, and whether escape sequences are supported (#3).

This can then be extended into a config file that works with custom dictionaries (#9) to allow the user to override existing file type definitions or add their own.

• scspell3k
• spellck
• misspell (rust)
• misspell (go)

We're developing a lot of flags. It'd be good if we added a config file so people can easily get a consistent experience

Copy the flags from ripgrep: https://github.com/BurntSushi/ripgrep/blob/master/src/app.rs#L745

Exposed as https://github.com/BurntSushi/ripgrep/blob/master/src/args.rs#L902

Idea comes from codespell
https://github.com/codespell-project/codespell

Some times files should just be ignore for spelling but work for all others

Right now --diff and --write-changes are only after everything is done happening. Not showing results as we progress can confuse the user.

The API has gone through some churn. We should audit it before 1.0 to make sure its something we want.

• Ignores binary / scm, see https://github.com/client9/misspell/blob/master/mime.go#L157
• Ignores emails, hostnames, paths, and c-escapes, see https://github.com/client9/misspell/blob/master/notwords.go and https://github.com/client9/misspell/blob/c0b55c8239520f6b5aa15a0207ca8b28027ba49e/replace.go#L103
  • And URLs, see https://github.com/client9/misspell/blob/master/url.go
• For go, only checks comments, see https://github.com/client9/misspell/blob/master/replace.go#L142

Possibly steal ripgreps cases

Compare to scspell, the go one that we took the list from, and some kind of baseline search, like ripgrep

https://github.com/codespell-project/codespell

Right now we proactively parse out lines and then parse within a line. What if instead we found out our line number by counting the new lines afterwards? This puts the cost on the typo case, which should be rare, rather than on every case when parsing

• We list the byte offset and not the column
• We point to the byte offset, and not the column, in the line

foo\nbar will look like foo and nbar without special handling.

With #14, we're going to have special handing of different file types but one file isn't always a single type

• markdown files that have code fences
  • treat markdown as non-code (no identifier support), `` as generic code, and code-fences as the specified language
• rust comments have markdown which have code fences
• mako files are a mixture of python and whatever the generated type will be.

Currently, all corrections force into a single english dialect. This will cause a lot more failures in a CI/. We should support any dialect.