Most of the time it's accurate, sometimes it is not:

error: spellcheck(Hunspell)
   --> /media/supersonic1t/projects/cargo-spellcheck/src/suggestion.rs:58
    |
 58 |  The span (absolute!) of where it is supposed to be used. TODO make this relative towards the literal.
    |                                                               ^^^^
    | - TOO, DODO, TO DO, TO-DO, TOD, TOTO, TODD, or one of 3 others
    |
    |   Possible spelling mistake found.

error: spellcheck(Hunspell)
    --> /media/supersonic1t/projects/cargo-spellcheck/src/literalset.rs:293
     |
 293 |  Convert a range of the linear trimmed (but no other processing) string represnetation to a set of
     |                                                                             ^^^^^^^^^^^^^^
     | - representation, reinterpretation, presentation, representative, or interpretation
     |
     |   Possible spelling mistake found.
     |

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behaviour:
0. Checkout rust-lang/rust.git with all submodules

1. Run 'cargo spellcheck check -v'
2. See error

thread 'main' panicked at 'byte index 113 is not a char boundary; it is inside '✓' (bytes 112..115) of `Possible ways to run rustc and request various parts of LTO.

VariantFlagObject CodeBitcoden/an/an/an/a✓✓✓✓`', /home/bernhard/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/str/mod.rs:1920:47
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Expected behavior

Exit like it does when passing an initial directory.

pwd
/yada/rust
cargo spellcheck check -v ../rust

works fine.

Screenshots
If applicable, add screenshots or copies of the commandline output to help explain your problem.
Use code blocks

Pplease complete the following information:

• System: [e.g. Fedora, Ubuntu, Win10, MacOS] Fedora
• Obtained: [i.e. git or cargo] cargo
• Version: $(cargo spellcheck --version) cargo-spellcheck 0.3.0-beta.4

Additional context

 bernhard@redbeard  .../rust   52d2c7ac948 ⛱  cargo-spellcheck check -v                                                                                                                                                                                                          14:21:49   0 
thread 'main' panicked at 'byte index 113 is not a char boundary; it is inside '✓' (bytes 112..115) of `Possible ways to run rustc and request various parts of LTO.

VariantFlagObject CodeBitcoden/an/an/an/a✓✓✓✓`', /home/bernhard/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/str/mod.rs:1920:47
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Follow up of #78

Describe an issue
If your config.toml file has a syntax and your run spellcheck with --cfg option there is such a error message.

Explicitly given config file does not exist

To Reproduce

Make a syntax mistake in toml e.g remove a " somewhere.

Expected behavior
Raise error with better message context for instance.

Provided config file has a syntax issue

Fix

Check error type here.

Please complete the following information:

• System: Arch
• Obtained: master

Describe the bug
In various places, the length used for offset calculation is used in bytes, which breaks Dow when multicharacter graphemes are used in literals.

To Reproduce
Currently there is a lack of unit tests to cover this issue sufficiently ( = none)

Expected behavior
Spans must be calculated based on graphemes (superset of chars) OR bytes consistently.

On the typing ? in the fixing dialog, the formatting is messed up:

Additionally, ? moves to the next entry without changing the current one.

It would be nice to have the github action that simplifies the usage of cargo-spellcheck on CI.

Hey @drahnr, I've seen your crate on rust weekly, and came here :). I just started with this crate so might I misunderstand something.

I am recently got set up an Arch distribution. And find out that it seems that pacman put hunspell dictionaries to /usr/share/myspell/dicts. This causes an inability to start --interactive mode. But spellcheck itself works.

[zhiburt@zhiburt scc]$ cargo spellcheck fix --interactive
error: /usr/share/myspell/en_US.aff: cannot open
error: /usr/share/myspell/en_US.dic: cannot open
error: /usr/share/myspell/en_US.aff: cannot open
Path is /home/zhiburt/proj/scc/src/main.rs and has 59

[zhiburt@zhiburt ~]$ ls -l /usr/share/myspell/
total 4
drwxr-xr-x 2 root root 4096 Jun 14 00:05 dicts
[zhiburt@zhiburt ~]$ ls -l /usr/share/myspell/dicts/
total 0
lrwxrwxrwx 1 root root 29 Feb 23 12:06 en_US.aff -> /usr/share/hunspell/en_US.aff
lrwxrwxrwx 1 root root 29 Feb 23 12:06 en_US.dic -> /usr/share/hunspell/en_US.dic
lrwxrwxrwx 1 root root 35 Feb 23 12:06 en_US-large.aff -> /usr/share/hunspell/en_US-large.aff
lrwxrwxrwx 1 root root 35 Feb 23 12:06 en_US-large.dic -> /usr/share/hunspell/en_US-large.dic

I resolved the issue just by moving the files to parent directory. But if the issue occurred itself not only on arch, I think that may adding a dict path to the look up places a good idea.

And I also checked the logs by setting CARGO_SPELLCHECK=cargo_spellcheck=trace, and noticed something. Is it supposed to continue analyzing the text even though it got an hunspell issue.

[2020-06-13T21:19:44Z DEBUG cargo_spellcheck::checker] Running Hunspell checks
error: /usr/share/myspell/en_US.aff: cannot open
error: /usr/share/myspell/en_US.dic: cannot open
error: /usr/share/myspell/en_US.aff: cannot open
[2020-06-13T21:19:44Z TRACE cargo_spellcheck::markdown] Parsing event (1..68): Start(Paragraph)
[2020-06-13T21:19:44Z TRACE cargo_spellcheck::markdown] Parsing event (1..68): Text(Borrowed("Prints shall tokens which are produced by lexical analyzer to outdo"))
[2020-06-13T21:19:44Z TRACE cargo_spellcheck::markdown] Parsing event (1..68): End(Paragraph)

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behaviour:

1. Run 'cargo spellcheck check'
2. Observe garbled rendering, ^^^^ are missing and the erronous line is not rendered

Expected behavior

The line to be rendered with ^^^^ underneath the erroneous word.

Screenshots

Pplease complete the following information:

• System: Fedora 32
• Obtained:cargo
• Version: cargo-spellcheck 0.3.0-alpha.1

I naturally was trying to exit the interactive mode by ctrlc/ctrlz but it's forbidden as I see, at least it doesn't work for me.

Might it's a good idea to add the ability to exit the interactive session or it's already done?

This would be a good foundation for third party extensions to provide i.e. in editor suggestions in i.e. vscode.

If the list is empty, inject the cwd + Cargo.toml and use that as base.

Describe the bug

Not handling UTF-8 well

To Reproduce
Steps to reproduce the behaviour:

in rust-lang/rust (52d2c7ac948d6abdc18eb9e05a53d03ddcaffd98)

> env RUST_BACKTRACE=1 cargo spellcheck
thread 'main' panicked at 'byte index 40 is not a char boundary; it is inside '♫' (bytes 38..41) of `///         println!("♫ Still alive ♫");`', /home/ivan/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/str/mod.rs:1920:47
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1076
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1537
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:218
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:490
  11: rust_begin_unwind
             at src/libstd/panicking.rs:388
  12: core::panicking::panic_fmt
             at src/libcore/panicking.rs:101
  13: core::str::slice_error_fail
             at src/libcore/str/mod.rs:0
  14: core::str::traits::<impl core::slice::SliceIndex<str> for core::ops::range::Range<usize>>::index::{{closure}}
  15: cargo_spellcheck::documentation::literalset::LiteralSet::into_chunk
  16: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
  17: cargo_spellcheck::documentation::Documentation::extend
  18: cargo_spellcheck::run
  19: cargo_spellcheck::main
  20: std::rt::lang_start::{{closure}}
  21: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:52
  22: std::panicking::try::do_call
             at src/libstd/panicking.rs:297
  23: std::panicking::try
             at src/libstd/panicking.rs:274
  24: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  25: std::rt::lang_start_internal
             at src/libstd/rt.rs:51
  26: main
  27: __libc_start_main
  28: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Expected behavior

No can do panic.

Screenshots
If applicable, add screenshots or copies of the commandline output to help explain your problem.
Use code blocks

Pplease complete the following information:

• System: [e.g. Fedora, Ubuntu, Win10, MacOS] arch linux
• Obtained: [i.e. git or cargo] cargo
• Version: $(cargo spellcheck --version) 0.3.0-beta.1

Additional context
Add any other context about the problem here.

#77

bash, zsh, fish, anything else?

Summary

Interactive replacement is only helpful if we have more "intelligence" on which replacement is the one to apply, since this depends heavily on the context, this either requires some stochastic learning and per project state.

Overview

I was willing to use grep on the spellcheck output and noticed that redirecting output by > or | will cause panic.
I see that the real output goes to stderr so it's not crucial.
I decided just to publish that but it's certainly not critical, even though hard to say why that's raised.

Reproduction

[zhiburt@zhiburt cargo-spellcheck]$ cargo spellcheck | grep ".md"
thread '<unnamed>' panicked at 'Failed to get stdout: Os { code: 25, kind: Other, message: "Inappropriate ioctl for device" }', src/main.rs:87:30
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Expected behavior

Probably don't having panic is a good one.

Pplease complete the following information:

• System: Arch
• Obtained: git 4dd8e0666b6c373d04f09fcd7b42a270e7c4fad9
• Version: cargo-spellcheck 0.3.0-alpha.1

Summary

Word splits are currently not validated, but each component of them. This should be a pass before sending it to the checkers.

Context

• Depends on #25
• Related to #39

hunspell only compiles under a unix like system as it seem, yet fedora already provides mingw64 hunspell and as such doing so would be no big deal.

Ref #14

Describe the bug
If you are will willing to create a config.toml file as showed in README.md the spell-check will not work.

The problem is that the code expects to get a config file in a slightly different format.
It expected to get a name of an object in lowercase because of Config structure.

In this situation the config is empty.

Config { hunspell: None, languagetool: None }

To Reproduce

Use the example of config file from README.md and run cargo spellcheck check

Expected behavior

Have a fresh documentation and predicted behavior according to it.

** Fix

There could be a fix of README.md by changing [Hunspell], [LanguageTool] to [hunspell], languagetool or add serde(rename="Hunspell"), serde(rename="LanguageTool") attributes to the fields in Config structure.

System information:

• System: Arch
• Obtained: master

Summary

Wrapping of doc comments is a nice addition to make the comments look nicer in code.

Probably requires a new set of parameters, i.e. line width (soft and hard limits) and how to deal with extra long link descriptions.

Is your feature request related to a use-case? Please describe.
Currently performance of #74 is far from acceptable, taking multiple seconds to complete for a small~ish codebase.

Describe the solution you'd like
The majority added delay comes from parsing CheckableChunk over and over again in order to convert ranges to spans and vice versa.

Describe alternatives you've considered
Not really many other options here, we need to get rid of the O(n) and make it a O(1) or O(log n) at least.

Summary

There are multiple variants here

[https://ahoi.io](https://ahoi.io)
[fun](../fun.html)
[struct Foo](super::Foo)

• detect valid urls in [] so spell checkings can be ignored in that span [https://ahoi.io](https://ahoi.io)
• links to struct items should be ignored in spell checks
• add a flag to verify the linked to destinations exist

Summary

Currently the same custom replacement has to be typed over and over again, for no reason.

It would be better to learn one instance and then re-run the checkers with the newly recorded item for the current doc comment and all remaining ones.

Will require some re-thinking,one of the following two:

check all items...

• lazily in interactive mode, i.e. by moving to an iterator only design.
• and recheck on every learned item, requires to record all decisions of the user made before

Relvenat files: interactive.rs ,hunspell.rs

Currently it's debatable if that is an actual use case, since an arbitrary suggestion might be contextually wrong, applying that blindly might do more harm than good.

Is your feature request related to a use-case? Please describe.
cargo spellcheck fix -i is slow, very slow - the time until the first result is displayed is significantly too long

Describe the solution you'd like
Move on to iterator based pipeline solution, consider per file threading.

Describe alternatives you've considered
Going full async with streams and multithreaded executor, but that seems out of proportion.

Additional context

Using inferno to extract some flamegraphs for cargo spellcheck check (so not interactive!) (cargo-flamegraph weirdly did not work) to get same base idea where time is being spent.

Currently there are quite a few places where single line issues are assumed, which is not necessarily true for grammar errors.

Required changes:

• fmt::Display for Suggestion must handle multiple spans, multiline spans and therefor fragmented ranges
• avoid Range types, use Span instead
• create complex cases

Summary

When excuting cargo spellcheck in a directory with a virtual manifest, it should dispatch to all sub projects.

Parsing is already done via cargo_toml and it should be no more than checking for Option<Workspace> in the struct Manifest as defined here https://docs.rs/cargo_toml/0.8.0/cargo_toml/struct.Manifest.html#method.complete_from_path

Relevant files: traverse.rs

Summary

Putting something in stdout frequently be a caused issues of displaying correct interface. I guess it's related to the usage of raw_mode.

Why it has a little importance because in debuging process you think that any issue may be caused by the debug changes.

For example adding a debug message in select_next will not work out properly.

     pub fn select_next(&mut self) {
+        dbg!(&self.pick_idx);
         self.pick_idx = (self.pick_idx + 1).rem_euclid(self.n_items);
     }

It copy the chosen line on each typing.

error: spellcheck(Hunspell)
    --> /home/zhiburt/proj/cargo-spellcheck/src/literalset.rs:176
     |
 176 |  but also the `LineColumn` in the proc_macro2 context.
     |                                   ^^^^^^^^^^^

(6/8) Apply this suggestion [y,n,q,a,d,j,e,?]?
 » macrocosmic
   ...

After some typing

   ...
   macrocosmic
 » macrocosmic
 » macrocosmic
 » macrocosmic
 » macrocosmic
 » macrocosmic
   macrocosmic
   macrocosmic
   macrocosmic
 » ...

Might debugging information to file here is not a bad idea? Or it's a bad idea ...

Context

• Prior discussion: low

As part of another issue, this is a quick and dirty flow graph of the current (v0.2.4) flow:

                              Documentation

                         +---------------------+
                         |                     |
                         |     LiteralSets     |
                         |  +------------+     |                      +----------------+
   +--------------+      |  |----------------+ |                      |                |
   |              |      |  |---------------------------------------->+   checker1     +------------+
   |              |      |  |--|Literal  |-| | |                      |                |            v
   |   rust       |      |  |--|Literal  |-| | |                      +----------------+          +-------------+
   |              +------------|Literal  |-| | |                                                  |             |
   |              |      |  |--|  +      |-| | |                                                  |  suggestion |
   |              |      |  |--|  |      |-| | |                      +----------------+          +--^----------+
   |              |      |  |--|  |      |--------------------------->+                |             |     |
   |              |      |  |--|  |      |-| | |                      |   checker2     +-------------+     |
   |              |      |  |--------------| | |                      |                |                   |
   |              |      |  +--------------| | |                      +----------------+                   |
   |              |      |     +-------------+ |                                                           |
   +----^---------+      |        |            |                                                           |
        |                |        |            |                                                           |
        |                +---------------------+                                                           |  user picks
        |                         |                                                                        |
        |                         |                                                                        |  replacement
        |                         |                                                                        |
        |                         |                                                                        |
        |                         |                                                                        |
        |                         |                                                                        |
        |                         |                                                                        |
        |                         |                                                                        |
        |                         |                                                                        |
        |                         |                                                                        |
        |                         | original literal span                                                  v
        |                         |                                                                 +----------------+
        |                         |                                                                 |                |
        |                         |                                                                 |                |
        |                         |                                                                 |                |
        |                         |                                                                 |                |
        |                         |                                                                 +----------------+
        |                         |                                                                       |
        |                         |                                                                       |
        |                         |                                                                       |
        |                         |                                                                       |
        |                  +----<-+                                                                       |
        |        BandAid |   |                             range/span within the extracte literal str   |
      <--------------------+   +<-------------------------------------------------------------------------+
                           |   |
                           +---+

Originally posted by @drahnr in #46 (comment)

Describe the bug
Error handling sucks

Expected behavior
There must be a clear distinction between an internal error and successful pass with spelling/grammar mistakes found.

A successful run (as in no internal errors) pass must exit with 0.
If mistakes are found, there shall be a flag which can be specified to set a special exit code for this case, i.e. for CI usage.
Any internal error (except for explicitly specified i.e. SIGINT 130) shall be 1.

Additional context
Implies a migration from anyhow to thiserror, which is also a foundation for #62

There are 3 layers:

1. proc_macro2::Literals with their proc_macro2::Span
2. TrimmedLiteral getting rid of " (leading and trailing)
3. A collection of consecutive TrimmedLiterals make a LiteralSet, only if they are consecutive
   4, PlainOverlay removes all markdown entities and provides a string with plain data only which can then be processed by $checker and map the results back using a Range based lookup table.

Rename:
plain -> reduced
markdown -> commonmark
_ -> raw

Summary

Currently the PR and issue templates are not very helpful, I find myself deleting most of the content.
It should be leaner, less bloat to delete.

Summary

When a individual line is longer than the terminal size, it should be ellipsized with .... Should probably be part of LiteralSet's fmt::Display impl.

Relevant files: literal*.rs

Is your feature request related to a use-case? Please describe.
With large code bases there are often special cases which are not easy to cover, some of them are more generic, others are very specific.

Issues faced 2x, 'gap' and some-thing should be all ok, but they are marked as possible spelling mistakes.

Describe the solution you'd like
A combination of regex quirks for the hunspell checker.
Possibly a configurable set of hardcoded quirks quirks=["single-quoted", "quoted", "multipicity-x-suffix", "dash-free-compound-words"] since that would give a speed gain compared to fancy-regex compilation and execution.

Describe alternatives you've considered
Spelling is hard, the only alternative would be to learn all of them, but that's a long shot #41 and would be very tedious for pre-existing code-bases.

Additional context

Required for adoption in the rust-lang/rust code base 🎉 rust-lang/rust#74697 (comment)

~/tmp$ cargo new testing --lib
     Created library `testing` package
~/tmp$ cd testing/
~/tmp/testing$ ls
Cargo.toml  src
~/tmp/testing$ vi src/lib.rs
~/tmp/testing$ cat src/lib.rs
/// Adds two numbrers.
fn add(a: i32, b: i32) -> i32 {
    a + b
}
~/tmp/testing$ cargo spellcheck
~/tmp/testing$ cargo spellcheck check
~/tmp/testing$ mv src/lib.rs src/main.rs
~/tmp/testing$ cargo spellcheck check
error: spellcheck(Hunspell)
  --> /home/kuba/tmp/testing/src/main.rs:1
   |
 1 |  Adds two numbrers.
   |           ^^^^^^^^
   | - numbers or number
   |
   |   Possible spelling mistake found.
   |

Error: Found 1 potential spelling mistakes

Triaging info

• Version: 0.2.2
• Did this used to work? No idea. This is the first time I'm trying to use this tool.

Describe the bug

It errors but the error should be incorrect.

To Reproduce
Steps to reproduce the behaviour:

1. git clone https://github.com/rust-lang/rust
2. cd rust
3. cargo spellcheck
4. Error: Failed to parse manifest file /home/ivan/src/pickfire/rs/rust/src/bootstrap/Cargo.toml: No such file or directory (os error 2)
5. File actually does exists, ls does show the file. Content:

[package]
authors = ["The Rust Project Developers"]
name = "bootstrap"
version = "0.0.0"
edition = "2018"

[lib]
name = "bootstrap"
path = "lib.rs"
doctest = false

[[bin]]
name = "bootstrap"
path = "bin/main.rs"
test = false

[[bin]]
name = "rustc"
path = "bin/rustc.rs"
test = false

[[bin]]
name = "rustdoc"
path = "bin/rustdoc.rs"
test = false

[[bin]]
name = "sccache-plus-cl"
path = "bin/sccache-plus-cl.rs"
test = false

[[bin]]
name = "llvm-config-wrapper"
path = "bin/llvm-config-wrapper.rs"
test = false

[dependencies]
build_helper = { path = "../build_helper" }
cmake = "0.1.38"
filetime = "0.2"
num_cpus = "1.0"
getopts = "0.2.19"
cc = "1.0.35"
libc = "0.2"
serde = { version = "1.0.8", features = ["derive"] }
serde_json = "1.0.2"
toml = "0.5"
lazy_static = "1.3.0"
time = "0.1"
ignore = "0.4.10"
opener = "0.4"

[target.'cfg(windows)'.dependencies.winapi]
version = "0.3"
features = ["fileapi", "ioapiset", "jobapi2", "handleapi", "winioctl"]

[dev-dependencies]
pretty_assertions = "0.6"

It is quite long but it also does not work for other directories as well.

Expected behavior

I don't know, it should check something.

Screenshots

> cargo spellcheck
Error: Failed to parse manifest file /home/ivan/src/pickfire/rs/rust/src/bootstrap/Cargo.toml: No such file or directory (os error 2)

Pplease complete the following information:

• System: Arch Linux - Linux arch 5.7.10-zen1-1-zen #1 ZEN SMP PREEMPT Wed, 22 Jul 2020 20:13:40 +0000 x86_64 GNU/Linux
• Obtained: cargo install --git https://github.com/drahnr/cargo-spellcheck cargo-spellcheck
• Version: 0.3.0-alpha.6

Additional context

Reference rust-lang/rust#74697 (comment)

Allow selecting the replacement string interactively, currently the first one is picked always

Summary

//! a doc comment
//! ```rust
//! /// currently this is not checked, can contain garbage
//! fn y() -> usize { 2usize }
//! ```


// I am ok!
struct Foo;

the inner documentation comments should also be checked as separate entity, as if the doc-test was a separate file.

Skeptic uses cmark just as we do, and the simplest approach would be to re-inject code blocks into the pipeline as virtual files.

Summary

Enable handling of *.md files, the infrastructure is already there and the handling that is necessary is mostly in traverse.rs and in documentation.rs

Is your feature request related to a use-case? Please describe.
recognise mdbook format toml and handle it

Describe the solution you'd like
either a separate project sharing most of the source files or a sub-mode cargo spellcheck mdbook book.toml

Describe alternatives you've considered
There is no alternative that is markdown aware.

/// comment causes a misalignment of the ticks equivalent to the number of spaces.

It'd be nice to provide copies of the license files for the MIT and Apache licenses in use for this project. It would also allow Github to detect what license(s) are in use.

languagetool includes hunspell on the backend, now both checkers provide a suggestion for the same item, which is pointless to the user and when fixing interactively, this will cause potentially broken file structure - i.e. when replacing the same word twice with words of different length.

Potential Solutions

Short term 🔰:

Using an iteration loop to check if overlaying issues are detected, if so prioritize one over the other (usually language tool provides the better suggestions).

Mid term:

Apply the changes of one checker before running the second checker. That way we have checkpoints.

Long term:

Consider tracking the line changes in chunks and adjust the spans that will be adjusted accordingly.

Summary

running into unimplemented! or being terminated via kill -9, the terminal is stuck in raw mode

Steps to reproduce

cargo spellcheck fix -i &; kill -9 $!

Expected results

terminal should return to it's previous state

Actual results

terminal is stuck in raw mode

Triaging info

• Version: 0.2.1
• Did this used to work? Nope

Installing cargo-spellcheck fails under Windows 10:

cargo install cargo-spellcheck
Updating crates.io index
Installing cargo-spellcheck v0.1.0
...
Compiling hunspell-sys v0.1.3
error: failed to run custom build command for hunspell-sys v0.1.3

Caused by:
process didn't exit successfully: C:\Users\<...>\AppData\Local\Temp\cargo-install3YNVZA\release\build\hunspell-sys-9a099962c3dfc468\build-script-build (exit code: 101)
--- stdout
running: "autoreconf" "-ivf"

--- stderr
thread 'main' panicked at '
failed to execute command: Das System kann die angegebene Datei nicht finden. (os error 2)
is autoreconf not installed?

build script failed, must exit now', C:\Users<...>.cargo\registry\src\github.com-1ecc6299db9ec823\autotools-0.2.1\src\lib.rs:449:5
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

warning: build failed, waiting for other jobs to finish...
error: failed to compile cargo-spellcheck v0.1.0, intermediate artifacts can be found at C:\Users\<...>\AppData\Local\Temp\cargo-install3YNVZA

Caused by:
build failed

I have installed hunspell with chocolatey. But it does not help. Chocolatey does not install any libs and it seams that hunspell-sys contains the hunspell code and tries to build it with the autotools, which just are not available under Windows.

I recognize, that the error is not in cargo-spellcheck itself but in its dependencies. Has someone expirence to install cargo-spellcheck under Windows? If yes, it would be nice to document, how to do this.

Describe the bug
All spelling mistake prints go to stderr.

To Reproduce
Steps to reproduce the behaviour:

1. Run 'cargo run -- check > dump`

Expected behavior
All output is in file dump

Please complete the following information:

• System: Fedora
• Obtained: git

Initially found by @zhiburt