Spellchecking based on Tree-Sitter queries?

[connorlay]

For a bit of background: I've been writing a lot of documentation lately for Phoenix Live View and Helix is my daily driver 🧬 ⚗️

Would the maintainers be interested in accepting a PR to Helix core that adds a built-in spellchecker that uses tree-sitter queries to determine what parts of the document to spellcheck? For example, consider the following Elixir code:

@doc "This documentation contains a tyyyypo"
def this_function_also_contains_a_tyyyypo do
  # mooooore typooooos
end

As a user, I would like the text inside of the comment string and the @doc to be spellchecked against my preferred language (in this case, en-US), but not the Elixir identifiers themselves. The tree-sitter queries could look something like this:

(comment) @spellcheck

This would allow for syntax-aware spell checking for each language and would be customizable for each user. Typos could be represented as diagnostics, possibly even with a list of close matches to a known dictionary?

See https://github.com/lewis6991/spellsitter.nvim for an example of what I am thinking of 🙂

[David-Else]

Sounds great, my only thought is that https://github.com/valentjn/ltex-ls has proven to be the ultimate spell and grammar checker, could you integrate that somehow? At the moment it needs some special features to work that are not part of the lsp spec. There is a plugin version for nvim, https://github.com/vigoux/ltex-ls.nvim that implements those features, could it be ported to Helix?

[connorlay]

Interesting, I haven't seen the LTeX language server before. I don't see why this could be added to Helix once #2507 is merged? Supporting non-LSP features would probably need to be handled by a plugin, or a wrapper similar to how https://github.com/typescript-language-server/typescript-language-server wraps the non-LSP features of tsserver.

That being said, I would not personally use such a language server and would rather have something simple and built-in to Helix. I don't want or need an automatic proof reader, all I want is a simple spell checker to help me since I am not the greatest touch typist (or speller) 😅

[mandarvaze]

💯 for ltex-ls I use it everywhere (Emacs, neovim) I would love to see helix support it.

[getreu]

A short blog post about Helix and ltex-ls: Jens Getreu's blog - Note talking with Helix, Tp-Note and LanguageTool

Comment in Discussion #3756 · helix-editor/helix

[the-mikedavis]

Using tree-sitter to determine what should be spell checked sounds like a good idea to me 👍

Spell-checking in general though is a question mark: there isn't anything built-in at the moment or a way to plug in a checker like aspell. It would probably be worth some discussion whether that even belongs in the core or as a plugin.

I think it would be handy if LSP could be used to provide spell-checking capabilities. Maybe languages could inject a language like we do for tree-sitter-comment or markdown in docs and the spelling language server could act on the injected ranges (although currently injected content can't be adressed by a language server afaik).

[connorlay]

@the-mikedavis One approach we could take if we wanted this to be built-in is to use Enchant via the enchant crate. Apparently enchant is the spell checker that Emacs uses, and it supports multiple different back-ends so it should be fairly portable and customizable if needed. Should this be in core? Based on the design goal of "Modern and sane builtin features" mentioned on https://helix-editor.com I think so 🙂

[connorlay]

If we wanted something simpler, there is the ispell crate that we could use to call ispell, aspell, or hunspell.

[the-mikedavis]

I worry that building in spell checking would take a lot of work/code for something that can already be done by LSP (although it would need #2507). Enchant doesn't look like too much code but I'm not sure how the dictionaries fit in - would we need to distribute dictionaries for languages?

With supporting multiple languages, I think spell checking has the possibilty to be too large in scope to be good for core. Like a magit mode or #1976, it would be great if it were in core but scope-wise it may be large enough to be a project on its own.

[connorlay]

@the-mikedavis I started a proof-of-concept draft PR exploring what a built-in spell checker could look like using the ispell crate and aspell: #3830 There's still much to do, but you can get the idea of how things look if you want 🙂

Regardless if you decide this approach makes sense or not to include in core, I'm learning a lot by implementing it 😁

[kirawi]

Microsoft recently released a blog post on how they introduced spell checking to Visual Studio: https://devblogs.microsoft.com/visualstudio/visual-studio-spell-checker-preview-now-available/

[the-mikedavis]

I've come around to the other side on this since my last comment ☝️: I think it's reasonable to have spell-checking as a core feature. Finding system-installed dictionaries is fairly straight-forward and fits well into helix-loader, plus it's easy to manually install dictionaries from a source like JetBrains/hunspell-dictionaries if necessary. Diagnostics for incorrect words can fit squarely into the LSP diagnostics code and we can re-use much of the code-actions code for suggesting corrections and providing a way to allow/forbid words in your personal dictionary. Delegating to a language server works well for prose languages but tokenization is difficult for code (i.e. splitting code into words that can be looked up in the dictionary), and we should be in a nice spot to do this robustly per-language with tree-sitter.

Spell checking also requires some other advancements in core that we want for other features like running tree-sitter queries across language injections (like for rainbow brackets, textobjects, indents) and segmenting a whole buffer into words efficiently (useful for- but maybe different than lexical autocomplete).

Specifically about spell-checking, we really only need the ability to: create an in-memory dictionary from Hunspell .dic and .aff files, check if a word is in the dictionary, and suggest corrections. Personal dictionaries would be nice to include but could be a follow-up.

The existing options we have (hunspell, nuspell, enchant) are a bit annoying from a build perspective: we would need to depend on the presence of libenchant or hunspell as a library at build-time and use FFI, so spell checking as a feature would probably need to be optional. I'd really like to avoid complicating the build or increasing our dependency on C(++) codebases so as archseer mentions, I'm working on a pure-Rust spell-checker compatible with Hunspell dictionaries. I'll make the repo public and push up an integration branch once the project matures some more.

[jerabaul29]

As #2507 has been released as part of 23.10, could / should this discussion be revisited? :) In my experience, good spellcheck also in a coding environment (not just pure markdown or text) per se is already quite useful at catching a number of "stupid" bugs :) .

My questions:

• I guess that there is no reason any longer given Add support for multiple language servers per language #2507 to not use (if need be custom per language) LSP(s) for providing spellcheck on all all kinds of relevant files?
• have some users special experience with using LSP-based spellcheck across file types and have recommendations? Ideally, could a tiny bit of extra config be added to get spellcheck-through-LSP out of the box / could such an example be added to the documentation for n00bs like me to just copy paste? :)
• I understand that @the-mikedavis solution above sounds more attractive on the long run, but would a slightly "ad hoc" solution based on other existing LSPs or similar be possible in the meantime?
• should spellcheck status / support be reported in ```helix --health````? (I guess it does not make sense to report it on a per language basis if it can be shared across languages?)?

[weakish]

@akhilman Does diagnostic-language-server support code actions (e.g. replace the word with suggestions, add word to dictionary, etc)?

[jerabaul29]

Yep, the repo is private for now and I'm squatting the crate name :P. Spellbook can currently spell-check reasonably well (missing some features for compatibility with aspell) but suggesting corrections will take a while to work out. [...]

@the-mikedavis just being curious: would you be ok to make the corresponding repo public, even if it is just in a very early form? I am trying to look a bit about the different options available and it would be very useful to see your work on this, even if it is preliminary :) (for example, I am still a bit unsure if I want to import a big LSP that offers suggestions, or if I am happy to start with something small that just highlights misspellings that I then 99% of the time can fix myself easily :) ).

[the-mikedavis]

I'm working on Spellbook actively again but I'm rewriting it based on Nuspell rather than Spylls for performance and correctness. The part about "Spellbook can currently spell-check reasonably well" is not the case at the moment but my plan is to open up the repo after the check algorithm is done. Without a full implementation of check though the project is pretty useless. There would be way too many false positives.

Suggestions and personal dictionaries could be done as follow-up. Plus the suggestion algorithm is simpler than check. My plan is to start small with a :spell typable command that segments the words in the current view, or maybe the whole buffer. But this is still a ways out so for now you're better off relying on a language server.

[gauteh]

Hey, thanks for this great project! Want to add my name to list of people anxiously awaiting this functionality (no pressure..). Again thanks for the great work!

[jerabaul29]

For now using blopker/codebook#30 (comment) , and it works well! Easy to install and set up.

[akhilman]

Nope, it does not. New words could be added to a custom dictionary file in the project directory.

…

On Fri, 2024-01-26 at 06:01 -0800, weakish wrote: @akhilman Does diagnostic-language-server support code actions (e.g. replace the word with suggestions, add word to dictionary, etc)?

[David-Else]

Vale now has a language server, and tree sitter based spell checking for comments in programming languages like Rust!

https://github.com/errata-ai/vale/releases/tag/v3.5.0

https://github.com/errata-ai/vale-ls (needs vale installed)

I have not tried it in Helix yet, but it looks like it could be perfect.

[sbromberger]

I got vale working in Helix. It's really good.

One other one to try out is https://github.com/tekumara/typos-lsp - I was using this beforehand. It has really low false-positive rate but a higher false-negative rate due to the fact that it has a predefined list of common misspellings and only alerts on those. It's fairly comprehensive, though!

[sbromberger]

Sure. Here's the languages.toml entry:

[language-server.vale]
command = "vale-ls"

Then you just add it to whatever language config you want.

As far as installation goes, you'll need both vale and vale-lsp binaries on your path. I used a release of vale from the github releases page, but built vale-lsp from a git clone (using cargo install . from the cloned source directory). Then I created ~/.config/vale/.vale.ini using the contents of the configuration generator (https://vale.sh/generator), and ran vale sync from the terminal. Everything just worked.

[David-Else]

I added it to the WIKI: https://github.com/helix-editor/helix/wiki/Language-Server-Configurations#vale-ls

[jsco2t]

Has anyone else had luck getting this to work?

I have both vale and vale-ls installed. Both are in my path.

I have these in my languages.toml file:

[language-server.vale]
command = "vale-ls"

[[language]]
name = "markdown"
language-servers = ["vale"]
text-width = 100
rulers = [100]

When I open a Markdown file - it doesn't appear that Vale is running as an LSP. I can misspell words, write incorrect grammer - nothing happens.

When I check the log file for Helix - this is the only message that I see:

2024-09-04T11:35:23.779 helix_term::application [WARN] unhandled window/showMessage: ShowMessageParams { typ: Error, message: "missing field `Path` at line 4 column 1" }

If I ask Helix to restart the lsp using :lsp-restart the message in the editor UI is "Language server exited". The helix log is updated with:

2024-09-04T11:45:59.548 helix_lsp [ERROR] client was already removed
2024-09-04T11:45:59.548 helix_lsp::transport [ERROR] vale err: <- StreamClosed
2024-09-04T11:45:59.668 helix_term::application [WARN] unhandled window/showMessage: ShowMessageParams { typ: Error, message: "missing field `Path` at line 4 column 1" }

Version info if:

❯ hx --version
helix 24.7 (079f5442)

❯ vale --version
vale version 3.7.0

❯ vale-ls --version
vale-ls 0.3.8

[jsco2t]

I suspect that maybe vale-ls needs parameters to work correctly? Though that's really just a guess on my part. I could have something else messed up here.

[Rot127]

You need to add a .vale.ini file. No idea why they don't just provide a default one.

cat ~/.config/vale/.vale.ini 
MinAlertLevel = suggestion

[*]
BasedOnStyles = Vale

Edit: Ok, just saw you fixed it below.

[sbromberger]

I'm using vale-ls 0.3.7 and vale version 3.6.0 and all I have in my languages.toml is

[language-server.vale]
command = "vale-ls"

and things appear to be working.

[jsco2t]

I think I worked out my issue. To be clear - I have no idea if it's due to the versions of vale/vale-ls I have installed.

For whatever reason vale couldn't find the .vale.ini file if I put the file in: ~/.config/vale/.vale.ini. I could only get things to work if I put the .vale.ini file in my "home directory" ( ~/.vale.ini).

I verified this by running vale directly. When I had my Vale config file in directory ~/.config/vale/.vale.ini I could only get vale to run correctly if I explicitly specified the config file path:

vale README.md --output=JSON --config="$HOME/.config/vale/.vale.ini"

My fix (as mentioned above) was to create a .vale.ini file in my home directory. I didn't want vale to create it's artifacts in my home directory though - so I adjusted the styles path in it as follows:

❯ cat .vale.ini
StylesPath = .config/vale/styles

....file continues

[sbromberger]

I do not have a ~/.vale.ini. I do have ~/.config/vale which contains .vale.ini and styles/ and native/ subdirectories, both empty.

My ~/.config/vale/.vale.ini contains

StylesPath = styles
MinAlertLevel = suggestion
Packages = Google, Readability

[*]
BasedOnStyles = Vale, Google, Readability

[jsco2t]

That's super interesting. Thanks for sharing @sbromberger. No idea why my environment works differently.

¯\_(ツ)_/¯

Appreciate you following up!

[sbromberger]

Use the configuration tool (https://vale.sh/generator) to generate your .vale.ini file :)

[jsco2t]

I did use that :)

[jsco2t]

To be clear - I don't think the issue was the .vale.ini content. I think (for reasons I don't completely understand) in my environment Vale was not locating the .vale.ini when it was placed under ~/.config/vale/.vale.ini

[joshbainbridge]

One other option that was recently shared on the Helix Matrix chat is Harper. This is the best LSP solution that I've tested so far. It's very fast and can be installed using cargo. Will work for both text based documents as well as comments. Another good option until we have @the-mikedavis's solution.

Configuration is in the wiki: https://github.com/helix-editor/helix/wiki/Language-Server-Configurations#harper-ls

[sbromberger]

Sorry to ask an unrelated question here, but for those of you who have tried both Harper and Vale, could you post your thoughts comparing the two?

[sbromberger]

It seems to work with markdown, but doesn't work with .txt. I wonder why that is.

[jameynakama]

I can't get Harper to do anything in Python files. Green check mark in hx --health and my settings seem correct. But I just don't see it doing anything.

[sbromberger]

Are you passing --stdio in the arguments?

Specifically: Automattic/harper#150 (comment)

[jameynakama]

Yes.

[[language]]
name = "python"
language-servers = ["pylsp", "ruff", "harper-ls"]
auto-format = true

[language-server.pylsp.config.pylsp]
plugins.pylsp_mypy.enabled = true
plugins.pylsp_mypy.live_mode = true

[language-server.ruff]
command = "ruff"
args = ["server"]

[language-server.harper-ls]
command = "harper-ls"
args = ["--stdio"]

[kirawi]

#11660

[justinlovinger]

I don't get why people are getting so bend out of shape about this feature.

As one of the dissenting voices, I am going to echo what @sbromberger said, I think "getting bent out of shape" is overly strong language. I disagree with the decision and am discussing it in the hopes of coming to a better understanding for everyone, myself included. I will continue to use Helix regardless of the outcome.

[the-mikedavis]

Splitting out a spellchecker into a separate project that communicates over LSP is a viable alternative but it would mean duplicating a lot code and also needlessly duplicating memory and work at runtime. Plus it means overhead of configuring and installing a language server.

[sbromberger]

@the-mikedavis not to mention, it's already been done by several other packages.

[justinlovinger]

it would mean duplicating a lot code

I imagine organizing the tree-sitter code into a common library could eliminate most of the code-duplication. It could be a good refactor anyway.

also needlessly duplicating memory and work at runtime

How much runtime overhead would we be looking at in practice? It is my understanding tree-sitter is very fast and relatively lightweight.

On a related note, once we get plugin-support, spellchecking could be a good candidate for a plugin. It could ship with Helix and still be enabled by default.

[kirawi]

I imagine organizing the tree-sitter code into a common library could eliminate most of the code-duplication. It could be a good refactor anyway.

This is already happening by the way

[justinlovinger]

#11660 (comment)

I spent a non-trivial bit of time setting up LSP's (in my case Vale) just so that I could get spell-checking in Markdown docs.

Your mistake may have been trying Vale first. Vale is significantly harder to set-up than Harper. Better documentation for how to set-up a spellchecking LSP could alleviate this issue.

[jsco2t]

I accept that - and as it happens now that I have used Harper I agree that it's a solid solution for Grammar + Spelling. That being said. I would still vastly prefer a native solution for spell checking. A native solution should open up more opportunities in terms of where spell checking can happen while also allowing the spell-checking solution to be highly optimized.

Just my 2 cents. I totally get others have a different perspective on this.

[jsco2t]

Also - I really appreciate the follow-up. I missed mentioning that above.

[justinlovinger]

A native solution should open up more opportunities in terms of where spell checking can happen while also allowing the spell-checking solution to be highly optimized.

LSP-based spellcheckers can also use tree-sitter for spellchecking in code, and many do. Helix already plans to splits its tree-sitter code into a library. At that point, LSP-based spellcheckers could use the exact same code-traversal Helix would use for spellchecking.

The only actual downside to using a LSP-based spellchecker is performing tree-sitter calculations twice. However, given tree-sitter is incremental and very efficient, it is not clear how much of a downside that actually is in practice.

[the-mikedavis]

The time and memory varies with the different parsers/scanners of each language, as well as disk space of a parser - some are fairly large. In the common case it's pretty fast but there are degenerate cases that can take hundreds of milliseconds to parse. A language server would also mean duplicating the document in memory between Helix and the server. It's definitely possible but needlessly wasteful and - again - a worse experience as you would need to configure and install an extra server. I don't see any advantage in scoping this as a plugin: it would mean either shelling out to Hunspell/Nuspell/Aspell (this is what Kakoune does) or writing a new spellchecking library in Scheme.

My take is that basic spellchecking fits as a core feature. It's a subjective judgement and disagreeing is fine, though this thread seems to me to be falling into whataboutism and hand-wringing. It's an additive feature with a reasonably small footprint that can benefit anyone who doesn't already have a prose checking setup, is potentially capable of spellchecking within code (not comments), and doesn't threaten existing prose-checking setups.

[justinlovinger]

#11660 (comment)

With helix we are in a position where we do have a universal parser for every language and that means we can enable a much more reliable spellchecker.

Harper also uses tree-sitter for spellchecking in code, just like Helix would.

[David-Else]

Vale also uses tree-sitter: https://github.com/errata-ai/vale/releases/tag/v3.5.0

This release includes improved, tree-sitter powered support for linting comments in Go, Rust, Python, Ruby, C/C++, JavaScript, TypeScript, YAML, and CSS files.

[the-mikedavis]

Both support a relatively limited set of tree-sitter parsers compared to our language support and only use tree-sitter to find comment nodes. We should also aim to find typos in code like struct fields for example.

[hholst80]

The point of Helix is that batteries ARE INCLUDED. Spell check should be a feature that comes out of the box. It certainly does that from its big brother Vim.

If it is not included users might as well use Vim + vendor meta package like AstroNvim.

[kirawi]

#11660

[jerabaul29]

I am now using codebook https://github.com/blopker/codebook , which takes spellbook https://github.com/helix-editor/spellbook and turns it into a LSP, while integrating with treesitter, logics with camelcase etc. Works like a charm, I can recommend. See the installation instructions at blopker/codebook#30 (comment) .