-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
internal: Clean up runnable lsp extension #17547
Conversation
/** | ||
* Environment variables to set before running the command. | ||
*/ | ||
environment?: Record<string, string>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Open to alternative names, should we be explicit with environmentVariables
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could also call it envVariables
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eh, I'll stick with environment
I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fair enough! not terribly attached.
/** | ||
* The working directory to run the command in. | ||
*/ | ||
cwd: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like this being mandatory gives a more unique experience across clients. We should not leave this decision to clients as that could result in runnables sometimes working sometimes not. (notable it is required by the shell version already)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, reducing the number of possible options is great. the combinatorial explosion of options made this really difficult to reason about.
r? @davidbarsky |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks good and reasonable to me.
@bors r+ |
internal: Clean up runnable lsp extension This feels like a natural addition to me, and also allows us to drop the expect-test hardcoding from the extension. Additionally, `cargoExtraArgs` is pointless, all the client will do is merge it with `cargoArgs` so the server can do that instead of delegating that to the client.
@bors r+ |
I'm a bit confused by #4604 (comment), in particular:
Does this refer to |
It does not. It refers to the field in the runnable sent from the server to the client. |
It refers to this rust-analyzer/docs/dev/lsp-extensions.md Line 382 in 78d5f05
rust-analyzer.cargo.extraArgs config yes. rust-analyzer.cargo.args isn't a thing, as the cargoArgs in the runnable is populated by the server depending on the task, its not something the user configures.
|
☀️ Test successful - checks-actions |
1 similar comment
☀️ Test successful - checks-actions |
👀 Test was successful, but fast-forwarding failed: 422 Changes must be made through a pull request. |
Thanks a lot for the clarification! |
See rust-lang/rust-analyzer#17547 * eglot-x.el (eglot-x--run-after-jump): Handle new property "environment". Still accept old properties to keep supporting old versions of rust-analyzer.
This feels like a natural addition to me, and also allows us to drop the expect-test hardcoding from the extension. Additionally,
cargoExtraArgs
is pointless, all the client will do is merge it withcargoArgs
so the server can do that instead of delegating that to the client.