LSP Support?

[epage]

Integrating this directly into an IDE in a standard way would probably help adoption.

[epage]

The big chicken egg problem is

• I don't use LSP
• I don't know how much implementing this would impact adoption to know if its worth it
• I won't know how much this would help adoption without implementing it.

[meain]

IMO this is not something that should be available as an lsp server as this not really the usecase for lsp. There is also a possibility that most editors will not work with multiple lsp servers for one language. This will cause problems if they want to run this alongside the language's lsp server.

This would go in a linter category and most editor should have a way to plug in a linter. But for those who want to use it through the lsp api could try using something like mattn/efm-langserver maybe?

[epage]

Thanks for your inisght. Like I said, I don't use LSP but this is something I saw people talking about, so I thought it'd be worth mentioning.

[GilShoshan94]

Hi, I think it would be amazing! And it would greatly help adoption.

To my understanding, a linter is the usecase for LSP. I am not aware of the limitation that editors will not work with multiple lsp servers for one language.

Other idea.

Maybe there is a way to easily integrate typos into existing LSP in a standard manner. So you don't need to worry about the LSP stuff, just get the input and output the result as json, the LSP will take care of the rest.

I am thinking that for example, rust-analyzer if using either cargo-check or cargo-clippy as its linter (and you can even pass config args). Maybe we could make a feature request to them for a spell checker?

Same for other LSP, if you take a Python lsp for example, it support a lot of various linters and formaters (Pyflakes, McCabe, ...).

It seems that spell checker are not standard "extension" of LSP yet but I don't see a reason why not. A spell checker is basically a linter, just focused on spelling...

---

More about LSP.

I looked arround and here are the ressources I could find:

• Official docs from Microsof (more oriented toward vscode, but still LSP)
  • https://code.visualstudio.com/api/language-extensions/language-server-extension-guide
  • https://github.com/microsoft/vscode-extension-samples/tree/main/lsp-sample
• NeoVim
  • https://neovim.io/doc/user/lsp.html
• Main crates for LSP (used in rust-analyzer)
  • https://docs.rs/lsp-server/latest/lsp_server
  • https://docs.rs/lsp-types/latest/lsp_types
• Other project that seems good, better documented
  • https://github.com/ebkalderon/tower-lsp
  • https://github.com/IWANABETHATGUY/tower-lsp-boilerplate

From what I could understand, a json output is required (typos has it with --format json),. And I am not sure if after it is just json message passing or jrpc...

It seems much more involved than the "other idea"

---

Or it has to be made as a custom plugging for each IDE.

[GilShoshan94]

Mention to https://github.com/rust-lang/rust-analyzer/discussions/14389 for the "other idea"

[GilShoshan94]

Hi again,

Following the discussion https://github.com/rust-lang/rust-analyzer/discussions/14389, the conclusion is:

1. Don't do an LSP. 2. The solution is to make a dedicated extension for each extension you wish to support.

I think this issue can be closed, and a new one "IDE extension support" should be open instead. By default I would say that making a vscode extension first seems to be the more benefical to help adoption as it is the more popular ide now.

But maybe do a poll to decide which idea to develop for first?

Here, for vscode extension: https://code.visualstudio.com/api/get-started/your-first-extension

[tekumara]

I personally would like a VS Code typos extension because I get too many false positives from dictionary-based spell checkers. I think it would be more efficient to run typos as a long-running server process, rather than invoke it for every document change. And if its a server process, it may as well be a LSP server and then you also get the benefit of multi-editor support.

The VS Code docs here suggest that linters are a valid LSP use case:

The first interesting feature a language server usually implements is validation of documents. In that sense, even a linter counts as a language server and in VS Code linters are usually implemented as language servers (see eslint and jshint for examples).

And in VS Code at least, it's possible to have multiple language servers for the same language per workspace.

I think the basic features of a typos LSP server could be:

• diagnostics - to identify typos
• code actions - aka quick fixes, to correct typos
• commands - to run typos over the whole file and apply fixes

I'm interested enough to work on an LSP server and vscode extension. Would you like me to contribute them back to this codebase?

[epage]

I'm assuming LSP would be fine though if there are places releases are supposed to get registered, I would be interested in knowing what that process is like. I try to keep the manual release steps minimal for typos.

For a vscode extension, my primary concern is that I don't use vscode and am not a JS dev and if external contributors don't keep up on it, it'll be abandoned. I would rather not pick it up in the first place in that case.

[tekumara]

I don't know of any LSP registry as such. The server could be either a separate binary, eg: typos-lsp or a flag in the existing binary that starts the server eg: typos --lsp if you preferred no change to the existing release process?

The vscode extension would need its own release pipeline and secrets to publish to the VS Code Extension Marketplace. Given your concerns it could be a separate repo. If the extension were to bundle the typos binary (which would avoid a two-step install), then there could be a build step in this repo that triggers the release pipeline for the vscode extension in the other repo.

[tekumara]

As per above, to get started, I've raised #710 for a basic LSP server.

I've also created a yet to be published, but working, basic vscode extension that uses the LSP server. I'm open to suggestions here but, in lieu of an alternative, for now it lives at tekumara/typos-vscode.

[mawkler]

@tekumara That's awesome that you're making an LSP out of typos! I use typos for spell checking inside of Neovim and wanted a code-action for correcting a word and for ignoring a spelling error, and found this issue.

It looks like typos-vscode is heavily coupled to VSC**e. To add the language server to Neovim I really just need the typos-lsp binary. What would be the best way of extracting typos-lsp? Is it available as a crate? 🙂

[tekumara]

Hi @mawkler typos-lsp binaries are now published on the tekumara/typos-vscode Github release page. If you have any questions, please feel free to raise an issue over there.

[mawkler]

@tekumara Awesome, thank you!