Merged
Conversation
7 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤔 What's changed?
Expose a
newWasmServerfunction that returns two streams for LSP.⚡️ What's your motivation?
To be able to start the server in-process in the VSCode extension. This allows us to control more of the server behaviour:
First, it lays a foundation for cucumber/vscode#81 and cucumber/blockly#23 because it makes it possible to start a 2nd language server for the Blockly editor, which will use an LSP client to retrieve all the steps.
However, as I am writing this, I realize that the Blockly editor isn't going to get the suggestions via auto-complete, because that only returns matching results for a string. It's going to need them all. It might be better to do something similar to
GherkinLanguageServer.reindex. Ot better, access the already indexed data from the server instance:In any case, this refactoring will make this possible.
Another benefit of this refactoring is preparing for cucumber/vscode#1
We could abstract file system access behind a simple
FileSystemAPI and pass in one that is backed by either https://code.visualstudio.com/api/references/vscode-api#FileSystem (which we would use in VSCode), or a Node.js file system implementation (for standalone mode - vim etc).This API would have operations for globbing. For VSCode we can use vscode.workspace.findFiles.
Solving this might be a milestone towards making the VSCode extension ready for GitHub Codespaces / github.dev
🏷️ What kind of change is this?
♻️ Anything particular you want feedback on?
📋 Checklist:
This text was originally generated from a template, then edited by hand. You can modify the template here.