Replies: 15 comments 62 replies
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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 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) 😅 |
Beta Was this translation helpful? Give feedback.
-
|
💯 for |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
|
@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 |
Beta Was this translation helpful? Give feedback.
-
|
If we wanted something simpler, there is the ispell crate that we could use to call |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@the-mikedavis I started a proof-of-concept draft PR exploring what a built-in spell checker could look like using the Regardless if you decide this approach makes sense or not to include in core, I'm learning a lot by implementing it 😁 |
Beta Was this translation helpful? Give feedback.
-
|
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/ |
Beta Was this translation helpful? Give feedback.
-
|
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 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 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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
|
Beta Was this translation helpful? Give feedback.
-
|
I have managed to add CSpell as a spell checker using diagnostic-language-server. Both run by Deno runtime. # Languages
[[language]]
name = "git-commit"
language-servers = [ "dls" ]
[[language]]
name = "markdown"
language-servers = [ "marksman", "dls" ]
[[language]]
name = "rust"
language-servers = [ "rust-analyzer", "dls" ]
# Language servers
# Diagnostic language server.
# See https://github.com/iamcco/diagnostic-languageserver .
[language-server.dls]
command = "deno"
args = [ "run", "--allow-read", "--allow-env", "--allow-run", "--allow-sys", "npm:diagnostic-languageserver", "--stdio", "--log-level=2" ]
[language-server.dls.config.filetypes]
"*" = "cspell"
# CSpell https://cspell.org/docs/getting-started/ .
[language-server.dls.config.linters.cspell]
command = "deno"
args = [ "run", "--allow-read", "--allow-env", "npm:cspell", "stdin" ]
sourceName = "cspell"
rootPatterns = [
".cspell.json",
"cspell.json",
".cSpell.json",
"cSpell.json",
"cspell.config.js",
"cspell.config.cjs",
"cspell.config.json",
"cspell.config.yaml",
"cspell.config.yml",
"cspell.yaml",
"cspell.yml",
]
debounce = 1000
formatLines = 1
formatPattern = [
"^[^:]+:(\\d+):(\\d+) - (.*) \\((.*)\\)$",
{ line = 1, column = 2, security = 3, message = [3, " (", 4, ")"] },
]
securities = { "Unknown word" = "warning" } |
Beta Was this translation helpful? Give feedback.
-
|
@akhilman Does diagnostic-language-server support code actions (e.g. replace the word with suggestions, add word to dictionary, etc)? |
Beta Was this translation helpful? Give feedback.
-
@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 :) ). |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
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)?
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
Sure. Here's the 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 |
Beta Was this translation helpful? Give feedback.
-
|
I added it to the WIKI: https://github.com/helix-editor/helix/wiki/Language-Server-Configurations#vale-ls |
Beta Was this translation helpful? Give feedback.
-
|
Has anyone else had luck getting this to work? I have both I have these in my [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: If I ask Helix to restart the Version info if: ❯ hx --version
helix 24.7 (079f5442)
❯ vale --version
vale version 3.7.0
❯ vale-ls --version
vale-ls 0.3.8 |
Beta Was this translation helpful? Give feedback.
-
|
I suspect that maybe |
Beta Was this translation helpful? Give feedback.
-
|
You need to add a Edit: Ok, just saw you fixed it below. |
Beta Was this translation helpful? Give feedback.
-
|
I'm using and things appear to be working. |
Beta Was this translation helpful? Give feedback.
-
|
I think I worked out my issue. To be clear - I have no idea if it's due to the versions of For whatever reason I verified this by running My fix (as mentioned above) was to create a |
Beta Was this translation helpful? Give feedback.
-
|
I do not have a My |
Beta Was this translation helpful? Give feedback.
-
|
That's super interesting. Thanks for sharing @sbromberger. No idea why my environment works differently. Appreciate you following up! |
Beta Was this translation helpful? Give feedback.
-
|
Use the configuration tool (https://vale.sh/generator) to generate your |
Beta Was this translation helpful? Give feedback.
-
|
I did use that :) |
Beta Was this translation helpful? Give feedback.
-
|
To be clear - I don't think the issue was the |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
It seems to work with markdown, but doesn't work with .txt. I wonder why that is. |
Beta Was this translation helpful? Give feedback.
-
|
I can't get Harper to do anything in Python files. Green check mark in |
Beta Was this translation helpful? Give feedback.
-
|
Are you passing Specifically: elijah-potter/harper#150 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
Yes. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@the-mikedavis not to mention, it's already been done by several other packages. |
Beta Was this translation helpful? Give feedback.
-
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.
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. |
Beta Was this translation helpful? Give feedback.
-
This is already happening by the way |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Also - I really appreciate the follow-up. I missed mentioning that above. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Harper also uses tree-sitter for spellchecking in code, just like Helix would. |
Beta Was this translation helpful? Give feedback.
-
|
Vale also uses tree-sitter: https://github.com/errata-ai/vale/releases/tag/v3.5.0
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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:
As a user, I would like the text inside of the comment string and the
@docto 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: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 🙂
Beta Was this translation helpful? Give feedback.
All reactions