Execute rubocop via rubocop's server

[pjg]

This ensures a much quicker execution on 2nd and any subsequent run. Otherwise there's always a 1-3 seconds delay before formatting is being applied (as rubocop is not that quick).

From rubocop's documentation:

--server If a server process has not been started yet, start the server process and execute inspection with server.

(documentation)

I've tested it locally with custom defined formatter and it resulted in a much quicker execution on subsequent runs. Best if someone else also tested this to confirm my observations.

An even better approach would be to use the LSP server, but I'm not sure how to achieve that (specifying the --lsp option wipes the buffer on each conform run for me).

[stevearc]

LGTM. If you want to use the --lsp, then you wouldn't use conform at all. You would just follow the instructions at https://docs.rubocop.org/rubocop/usage/lsp.html#neovim-nvim-lspconfig

[pjg]

Thanks! As far as rubocop's usage via LSP is concerned, my use case is slightly more complicated as I'm using conform to run both rubyftm and rubocop, one after the other. And rubyfmt currently only on certain file patterns. Ideally I should use just one nvim plugin for the job, which would allow me to run formatters/linters sequentially (which conform.nvim does). In other words, I believe conform should also allow me to run rubocop via LSP as one of the options to run it.

When using two tools, both attaching to BufWritePre, I'm not sure I will be able to maintain correct order of execution, something which is crucial to me. I'll experiment with it, though.

[pjg]

After some trials and tribulations I was able to make it all work the way I want. First, rubyfmt is being executed by conform.nvim, and after it finishes (sync execution), the result is processed/formatted by rubocop via LSP.

References:

• conform setup: pjg/dotfiles@2d6c577
• full file: https://github.com/pjg/dotfiles/blob/main/.vim/lua/init.lua