autozimu / LanguageClient-neovim

Language Server Protocol (LSP) support for vim and neovim.
MIT License
3.55k stars 273 forks source link

autofixers #1212

Open EvanCarroll opened 3 years ago

EvanCarroll commented 3 years ago

Describe the solution you'd like

The ability to have :w run a "fixer" before hand.

Describe alternatives you've considered

If using using this project to replace ALE I can go to Formatting under the F5 tool and it'll run everything through rustfmt. I would like the ability to configure that to happen every time on :w though.

martskins commented 3 years ago

You should be able to configure an autocmd for that. For example: autocmd BufWritePre *.go,*.rust call LanguageClient#textDocument_formatting_sync() would run formatting on save for rust and go files.

EvanCarroll commented 3 years ago

Cool for comparison in ale it looks like this,

let g:ale_fix_on_save = 1
martskins commented 3 years ago

Yeah, we could probably set something like that up, shouldn't be too hard. I think it was mostly a design decision, but I'm not opposed to the idea, I think it makes sense to make that easier for users considering how much everyone uses it.

EvanCarroll commented 3 years ago

I can see merit in providing the functionality or forcing people to do it the native vim way, but I'd document it either way. I looked for it before asking but I may have missed it.

martskins commented 3 years ago

Fwiw, adding the option would ultimately do it the same way, so it's not much of a big deal, it wouldn't be any different from any of the other options we provide already. Will see if I can add that at some point this week.

EvanCarroll commented 3 years ago

For reference when adding the option, I think the two variants that work

autocmd FileType rust autocmd BufWritePre <buffer> call LanguageClient#textDocument_formatting_sync()

or (with the extension)

autocmd BufWritePre *.rs call LanguageClient#textDocument_formatting_sync()

The method you provided didn't work for me.

martskins commented 3 years ago

@EvanCarroll See #1216 . As mentioned there, I think this needs a proper test ride, I think it should work, but there may be cases where the async nature of that call causes some issues. If you want to give that a try that'd be great.