This repository was archived by the owner on Jul 31, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Jul 31, 2023. It is now read-only.
Disabling LSP features (rcodetools, rubyLocate, formatting) #285
Description
If language server features are going to be offloaded to other providers (whether castwide.solargraph or something else), it might be practical to make features like rcodetools, rubyLocate, and formatting optional, if not removing them altogether, since there are potential issues with multiple providers performing redundant functions or interfering with each other.
Activity
[-]Disabling rcodetools and rubyLocate[/-][+]Disabling LSP features (rcodetools, rubyLocate, formatting)[/+]doudou commentedon Mar 6, 2018
Aren't they already ?
vscode-ruby does not run any of the code formatting/linting unless explicitely told to do so.
For what it's worth, I don't believe there is another rubocop integration extension, is there ?
wingrunr21 commentedon Mar 6, 2018
I think this extension should support a minimum set of features out of the box and then allow delegation to a more feature-rich implementation if a user chooses (sort of like how VSCode provides very basic out of the box Ruby support).
Formatting and linting IMO fit in this category but things like Intellisense do not
castwide commentedon Mar 6, 2018
There are a couple other extensions that use rubocop for linting and formatting. I also expect to use it in solargraph as part of its support for LSP.
Minimum features out of the box makes sense, but 1) where is the line, and 2) does the extension need configuration options to enable/disable them? I'm leaning toward yes for (2), since I've already run into a conflict with multiple definition providers giving redundant results; but maybe there's another way to resolve it?
Part of my concern also comes from open issues like #209 and #200, which @rebornix suggested as features that could be handled externally.
castwide commentedon Mar 6, 2018
@doudou To clarify, you're correct that linting needs to be enabled explicitly, but some of the other features do not.
wingrunr21 commentedon Mar 6, 2018
I may look through some of the JS community's solutions to these issues. There's a lot of conflicting tooling there so I'd be curious how they worked around things. I know for my personal setup that the extensions are more 'single responsibility' vs this extension which is trying to do everything.
castwide commentedon Mar 6, 2018
Good question. I don't know of a way, but it's worth looking into. When I tried to guard against conflicts, I resorted to explicitly querying one extension from the other, which is less than optimal.
I'll put some more thought into this as well. Looking to JS tools for inspiration is a good idea.
castwide commentedon Mar 8, 2018
I've started some changes in my fork of vscode-ruby for this and #263. I'm waiting to submit a PR because I'd like to hear some other opinions and feedback. Current status:
ruby.codeCompletioncan be set torcodetoolsorotherruby.intellisensecan be set torubyLocateorotherThe
otheroption disables the feature for when another extension provides it. This should allow vscode-ruby to be more agnostic to other language servers. One thought I had, if the options are simply to turn them on or off, maybe they should be booleans instead?I dug around to see if there was a way to automatically detect downstream providers, but couldn't come up with a strong solution.
gurgeous commentedon Mar 11, 2018
I think this is a positive direction. We want to offload work where possible and encourage an ecosystem of best-of-breed extensions rather than a single monolithic extension that moves forward at a glacial pace. Let @castwide lead the way with
solargraph!Another example - I want to use
rufofor formatting sincerubocopis too slow. Rubocop formatting is actually so slow that it doesn't currently work in vscode for me at all (see microsoft/vscode#41194). Unfortunately, in vscode-ruby formatting config is the same as linting config so it's not really possible to use vscode-ruby/rubocop with vscode-rufo. This is another area where we may need to specify "other".gurgeous commentedon Mar 11, 2018
BTW, I prefer
falseto'other'. Just a thought.castwide commentedon Mar 28, 2018
#309
wingrunr21 commentedon Apr 4, 2018
This will be addressed via #318