Vscode-ruby: Internal Language Server

[wingrunr21]

Implement an internal language server based on the toolkit Microsoft provides in vscode-languageserver-node

The underlying parsing will be done via tree-sitter-ruby vs the traditional regex approach

Target feature set:

• [x] Balanced pairs highlight support
• [x] Code folding
• [x] Linting (via rubocop, reek, fasterer)
• [x] Formatting (via rubocop or rufo) + inline formatting (like that specified in #200)
• [ ] Semantic highlighting. This would allow us to remove the "optimistic" classifications that are being added to the Ruby grammar and allow highlighting that more accurately represents the actual code that exists (#283, #296)
• [ ] Same file symbol suggestion (stretch goal)

Note:

I am proposing dropping support for ruby -wc, debride, and ruby-lint. Open to suggestions otherwise.

[gurgeous]

Neat. Any idea how we can plug in tree-sitter since it's written in C? Managing our Ruby dependencies is already pretty challenging...

I fully support ejecting things like ruby -wc, and whatever else we can realistically jettison.

[gurgeous]

More questions - should we hold off on PRs? What is your timeframe for the proof of concept? Maybe we should release master before we start in on the next batch... I'd be happy to contribute, but I'm unsure how to proceed.

[wingrunr21]

If it has to do with the language server, not sure how you'd PR something that doesn't exist. You could PR against the debugger features. Like I said in that tracking issue, it is independent of the language server work and needs love.

My timeframe is when I have time. Sorry to be blunt but this is definitely a "free time" thing for me. I have the proof of concept done but there are a few more minor details to work through until it's ready for a PR.

There's not really a "we" to release master. @rebornix is the only one who can do that. I think there needs to be a release cut anyway.

[gurgeous]

Oh, no worries. I'm just trying to ascertain if we should submit more PRs for language-related features (formatting, linting, highlighting). If the language server is under active development then we probably don't want to muck with things. Sounds like you are making great progress, no rush.

@rebornix - can we cut a new release? We're getting a fair number of incoming issues for things that are already fixed.

[wingrunr21]

The existing code is going to live alongside the new stuff for the immediate future so I think PRs against the existing codebase is fine

[gurgeous]

@wingrunr21 I'd be happy to start on the linting work. Specifically:

1. Add a linting test. Just one would be a great start.
2. Comment existing code
3. Convert js to ts and fix tslint errors, run prettier
4. Remove support for ruby -wc, debride, and ruby-lint
5. Investigate/fix/document linting issues like #238, #262, #307, #308

[rebornix]

@wingrunr21 I attempted to grant you privilege to publish this Ruby extension but unluckily it seems not possible as it's under my account. The package publishing part is easy as it only requires one command vsce publish, but it takes a bit of time to generate a proper release note / changelog, verify the bits (I did manual sanity testing before release). When you think the code ready for a new release, you can add a new tag and I'll do a publish.

[wingrunr21]

@gurgeous sure, but if you could write it such that I can integrate it into the language server later that'd be great. So, if you can take a document or a subset of that document as input to the linting code it should work both for the current use case and the new one.

[gurgeous]

I'll give it a shot!

[wingrunr21]

Balanced pairs is implemented. Reviewing the semantic code folding spec that hit in VSCode 1.21 and doing that implementation.

[wingrunr21]

Hoping to find time to come back to this this weekend. Work is super duper crazy right now and it is taking all my energy.

[scaryguy]

Any updates on this? It sucks to not have auto-formatting :

[wingrunr21]

You mean other than #366?

[wingrunr21]

Proof of concept language server was released this morning in v0.20.0!

Let me know if people have issues running it. Getting native binaries into a VSCode extension turned out to be tricky.

You will need VSCode >= 1.25.0 in order to run this version!

[wingrunr21]

Also make sure you take a look at the README section about it

[wingrunr21]

Thanks everyone for their patience on this! I've been trying to put time into this every morning before work as I know this extension is an important part of everyone's workflow. I'm aiming to have this extension in a really good spot by RubyConf this year!

Next up on my list (in order):

v0.21.0

• Multi-root workspace support
• Linting and formatting

v0.22.0

• Introduction of an analyzer that allows me to query the various constructs in the AST. This will make features like same-file Intellisense and additional highlight/code folding support considerably easier

Later this week I am also going to create a more detailed roadmap for various release milestones. I'd like to close this ticket after I do that so that end users can get additional detail on progress.

Thanks!

[natsumi]

@wingrunr21 great job! been waiting a long time for this and I'm happy to see it start to take shape.

I noticed a small issue with the balanced pairs. It only seems to highlight if I click on one of the pairs versus moving the cursor manually over one of the pairs.

It would be nice if it worked with normal cursor navigation also.

[wingrunr21]

@narinari hmm, yep you're right. I'll research that. Possible it is something with VSCode not sending a highlight request when the cursor moves.

[Rush]

Sorry if this was already mentioned. You could compile tree-sitter to WebAssembly (or ASM.js) and therefore work around the native module limitations.

[wingrunr21]

There are numerous reasons I don’t want to do that. Besides, tree sitter is already being shipped in the latest version

[rebornix]

Speaking of the native module thing, we can upgrade tree-sitter-ruby from NAN to NAPI and then we won't be bite when Electron updates. I can take a look at this issue when upgrading other libraries Code uses from NAN to NAPI.

[wingrunr21]

405 has been merged with support for most of the original issues here:

• Semantic highlighting is still not available in VSCode proper
• Same file symbol support will be added next as #405 was pretty big without it

[connorshea]

FYI the README still links to this issue

[wingrunr21]

Ya, haven't gotten to updating documentation yet

[guledali]

@wingrunr21 Can the new language server use the microsoft language server protocol for better integration with vscode(icons for function and classes)

[wingrunr21]

It does