Very simple approach: For each identifier, set the hash of the range
where it's defined as its 'id' and use it in the VSCode extension to
generate unique colors.
Thus, the generated colors are per-file. They are also quite fragile,
and I'm not entirely sure why. Looks like we need to make sure the
same ranges aren't overwritten by a later request?
As tested by @edwin0cheng, Windows requires the quotes removed in the
previous commit. This commit re-adds the quotes gated by an if statement
on the node environment, so that quotes are only added on Windows.
As of #1079 the VSCode cargo-watch functionality has been broken on
Linux systems.
The cause seems to be that linux takes the added quotes inside process
arguments literally, so it attempts to make cargo-watch run the command
`cargo "check --message-format json"` with the entire quoted part being
treated as a single long subcommand, which cargo doesn't know how to
handle.
Removing the extra quotes solves the issue.
This fixes#1005.
Defaults to `ask` which prompts users each time whether to start `cargo watch`
or not. `enabled` always starts `cargo watch` and `disabled` does not.
This allows users to control whether or not they want to see the "workspace
loaded" notification.
This is done on the server side using InitializationOptions which are provided
by the client. By default show_workspace_loaded is true, meaning the
notification is sent.
Previously when using the file based syntax tree, it would not update until a
change had been made in the new file. Now we automatically update the syntax
tree to match the current file.
This enables the client to use a command to either show the live-updating
version of the syntax tree for the current file. Or optionally when a selected
range is provided, we then provide a snapshot of the syntax tree for the range.
807: Specify vscode 1.31 r=matklad a=kjeremy
This is for #796
It doesn't seem to fix the problem if you manually install the extension but it is the "right thing to do".
Co-authored-by: kjeremy <kjeremy@gmail.com>
This further fixes problems when having a VIM extension (at least vscodevim)
enabled, by not calling `overrideCommand('type', commands.onEnter.handle)` when
enableEnhancedTyping is set to `false`.
The problem is dependent on the order in which extensions are activated, if
rust-analyzer is activated before `vscodevim`, rust-analyzer will register the
`type` command, and when `vscodevim` finally attempts to activate, it will fail
to register the command. This causes `vscodevim` to stop working properly.
This setting allows users to disable the registerCommand `type` in
rust-analyzer, allowing `vscodevim` to work. The setting defaults to `true`.
Currently changing the setting requires reloading of the window.
704: Feat/jinstall lsp r=matklad a=DJMcNab
Add `cargo jinstall-lsp` as a shorthand to include jemalloc support
Also activate the extension when the commands are run which is makes sense to activate.
I still need to work out what `Run` actually does to give it a better name, and other extensions through some voodoo magic are able to hide their commands from the command palette before the extension is activated, which would be a better fix.
705: Pass Documentation up to LSP and add "rust" to our codeblocks there r=matklad a=kjeremy
Fixes#699
Co-authored-by: DJMcNab <36049421+djmcnab@users.noreply.github.com>
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
500: Code lens support for running tests r=matklad a=kjeremy
Supports running individual and mod tests.
I feel like this kind of abuses the `Runnables` infrastructure but it works. Maybe later on down the line we should introduce a struct that is really just a tuple of binary, arguments, and environment and pass that back to the client instead. `run_single.ts` is just a paired down version of `runnables.ts` and there is duplication because I think run_single will probably change independent of runnables.
Co-authored-by: Jeremy A. Kolb <jkolb@ara.com>
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
