LSP server

[will]

This adds an LSP server that runs with the flag --lsp. It does the lsp jsonrpc over stdio. Functionality wise, this works for everything I need. I've only tested with neovim 0.8 though. It only operates on documents that you open, rather than going through your entire project looking for ruby files.

Test coverage isn't great, but I think they cover the major parts:

• telling the lsp client (an editor) on init what the server supports and to send full documents instead of patches
• getting diagnostics
• formatting

I'm okay with this level of testing to start, but I'd understand if you weren't.

I think this is a good starting point for functionality, but there some improvements left on the table:

If several changes come in while it was doing some other work, the stdin reader could collapse the changes and only take the last full change.

Editors could just send the small changes on each change, but then the server would have to be able to patch those into the copy it has in memory. Not impossible, but defiantly a lot more work. Would also make the previous collapsing improvement not necessary.

Format results could also be a series of patches rather than the entire document.

It could go through and find all the files in your workspace, but idk, I think just working on open files is good enough.

It might be possible to do the diagnostics and formatting in memory rather than bouncing through a tempfile. The solargraph moneky patch I was using before did this originally, but it stopped working and I couldn't figure out why, which lead me down to writing a small lsp form scratch in the first place.

Also please let me know what sort of git etiquette you'd like for changes on the PR. rebasing into the original commit or fixup additional patches or whatnot.

closes #472

[searls]

Thanks! Will review soon. I'd encourage you to use whatever git technique you like

[searls]

I dig your code style! Thanks for tidying a few things up.

What's the bare minimum setup I could use to test this actually working for myself locally?

[will]

Thanks :)

The most minimal config for neovim 0.8+ would be this, with replacing the path:

-- /tmp/init.lua
vim.opt.signcolumn = "yes" -- otherwise it bounces in and out, not strictly needed though
vim.api.nvim_create_autocmd("FileType", {
  pattern = "ruby",
  group = vim.api.nvim_create_augroup("RubyLSP", { clear = true }), -- also this is not /needed/ but it's good practice 
  callback = function()
    vim.lsp.start {
      name = "standard",
      cmd = { "/Users/will/code/standard/exe/standardrb", "--lsp" },
    }
  end,
})

Then you can edit a ruby file with it nvim -u /tmp/init.lua a.rb

It should auto do the in-line virtual text for diagnostics (which I find too noisy to have on all the time personally). Then to format you can do :lua vim.lsp.buf.formatting() which you would want to map to something like <leader>lf with an on_attach function, but it is not minimal to do that ;)

[foca]

Been playing with this on a personal project and it's fantastic 😄❤️

(Beyond the setup code on that vim config file, I also added an autocmd to format the code on BufWrite that works instantly :))

[searls]

Looks great to me, thanks @will!

[searls]

Landed in v1.19.0! Great work, @will. I'm super grateful for your initiative, your contribution, and your patience. I'm also really impressed with how well you structured your code similarly to what was already in place!

[will]

Thanks for the kind words and for merging it :)

[bluz71]

I was using Standard Ruby via null-ls inside Neovim. I just switched over from that to the new LSP option, and the difference is incredible.

From very slow, to near instant. Wow!

null-ls invokes the standardrb command line on each edit and the lag is very noticeable; up to 2 seconds (sometimes more).

The new --lsp option on the other-hand is near realtime; I never thought that was possible for anything related to Rubocop. But seeing is believing.

This feature needs to be advertised wide and far; especially integration into nvim-lspconfig.

From I have seen, this simple LSP addition easily competes with Shopify's Ruby LSP which appears to be focussed on diagnostics and formatting, but not completion (similar to this new --lsp option).

Note, I still use Solargraph for code completion and navigation (whilst disabling diagnostics and formatting). Two LSP's running at the same time, with no overlap, works just fine.

Great work @will and @searls.

[will]

Thanks @bluz71 it's very nice to hear that you like it :)