null-ls.nvim
null-ls.nvim copied to clipboard
jose-elias-alvarez
diagnostics: add LanguageTool support (by ltrs)
Adding support for LanguageTool. LanguageTool is an online service to help you to correct blocks of text. It is a writing assistant, quite similar to other services like Grammarly.
More info: https://languagetool.org/
I think it can be handy to have an integration in NeoVim to help people to write better documentation, commit messages, etc.
This integration is performed thanks to languagetool-rust. A Rust implementation that interact with LanguageTool API.
This Null-ls Builtin adds diagnostics and code actions capabilities.
Some screenshots:
Looks great! I'll have a chance to test this later in the week and will give more detailed feedback then.
LTRS maintainer here. Do you know if Null-ls has a way to take care of starting and stopping the server it uses? I am currently working on an integration with Docker and I might design my interface based on that response :)
@jeertmans The current architecture of null-ls assumes that each run of a command is self-contained, so the status quo is ideal from our point of view. It would be pretty simple to add hooks that run before a command's first run or upon exiting, but anything more complicated than that (e.g. continuous communication via stdio) would be tricky.
I hope you don't let that constrain the design of LTRS, though! null-ls is ultimately meant to cover gaps in the ecosystem, so if you want to go in a different direction, please feel free to do so.
Thank you @jose-elias-alvarez ! This will definitely not constraint the design :-) Are those possible hooks directly included into null-ls, or to be set up separately?
Are those possible hooks directly included into null-ls, or to be set up separately?
Not implemented yet, but it would be pretty easy to add in the ability to run an arbitrary Lua function on start / stop!
I tested this out and it works well, though there's a noticeable delay when requesting code actions. #915 deals with a similar issue with cspell by re-using the diagnostics generated by the diagnostics source instead of spawning a new process. This has the downside of making the code action source dependent on the diagnostics source, but it should be safe to assume that users will want to use them together.
What do you think? I'm also OK merging this as-is for now and seeing if we can incorporate potential future changes later on.
Awesome! Right now I'm a bit busy to implement this improvement. If you are ok with the current code, merge it and I'll work as soon as I have more free time. 👌
This should be good to merge for now, we can investigate performance improvements in the future. Thanks!