3308: vscode: fix vscode-vim keybindings conflict r=matklad a=Veetaha
Closes#3013 I hope
vscode-vim extension overrides the `type` command so that it prevents
some keypresses to reach the text document editor.
It conflicts with our `onEnter` keybinding
that is used to support automatic doc comments extending and
indentation insertion.
The VSCode-native way to implement this would be
to use regular expressions, but as per matklad it is
considered not acceptable for the language server.
Thus we implement it via a `Enter` keybinding that
invokes our `onEnter` command which does it via the language-server.
At the end of the day we may only apply
ad hoc workarounds for conflicting extensions.
But vscode has another bug for that. You
either cannot use parantheses in `when` condition
of a keybinding or it just malfunctions.
See an issue about that here: https://github.com/microsoft/vscode/issues/91473
To get the ultimate context, follow this [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Enhanced.20typing)
Co-authored-by: Veetaha <gerzoh1@gmail.com>
vscode-vim extension overrides the `type` command so that it prevents
some keypresses to reach the text document editor.
It conflicts with our `onEnter` keybinding
that is used to support automatic doc comments extending and
indentation insertion.
The VSCode-native way to implement this would be
to use regular expressions, but as per matklad it is
considered not acceptable for the language server.
Thus we implement it via a `Enter` keybinding that
invokes our `onEnter` command which sends
a request to rust-analyzer process and applies
the appropriate source change recieved from it.
At the end of the day we may only apply
ad hoc workarounds for conflicting extensions.
But vscode has another bug for that. You
either cannot use parantheses in `when` condition
of a keybinding or it just malfunctions.
See an issue about that here: https://github.com/microsoft/vscode/issues/91473
To get the ultimate context, follow this zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Enhanced.20typing
3099: Init implementation of structural search replace r=matklad a=mikhail-m1
next steps:
* ignore space and other minor difference
* add support to ra_cli
* call rust parser to check pattern
* documentation
original issue #2267
Co-authored-by: Mikhail Modin <mikhailm1@gmail.com>
3162: Feature: vscode always downloads only the matching ra_lsp_server version r=matklad a=Veetaha
I tried to separate logically connected changes into separate commits, so enjoy!
Now TypeScript extension saves installed binary version in global state and always checks that the installed binary version equals the version of the TypeScript extension itself (to prevent version drifts).
Also, changed `fetchLatestArtifactReleaseInfo()` to `fetchArtifactReleaseInfo()` that takes an optional release tag (when not specified fetches the latest release). The version without a release tag will be useful in the future when adding auto-checking for updates.
I decided not to do `Download latest language server` command (I have stated the rationale for this in #3073) and let the extension itself decide which version of the binary it wants. This way the users will be able to get the latest `ra_lsp_server` binary after the approaching 2020-02-17 release, without having to manually delete the outdated one from `~/.config/Code/User/globalStorage/matklad.rust-analyzer`!
Closes#3073
Co-authored-by: Veetaha <gerzoh1@gmail.com>
3131: vscode: simplified config and to removed one source of truth of default values r=matklad a=Veetaha
Though not intended initially, the implementation of config design is alike [dart's one](https://github.com/Dart-Code/Dart-Code/blob/master/src/extension/config.ts) as pointed by @matklad in PM.
Co-authored-by: Veetaha <gerzoh1@gmail.com>
3137: Do not register all proposed features r=matklad a=kjeremy
Instead only opt-in to CallHierarchy since it has a vscode API but LSP support
is still proposed.
Discovered while working on SemanticTokens which does not have a vscode API
and is still in the proposed state. Somehow enabling it would crash the
language server.
See https://github.com/microsoft/vscode-languageserver-node/issues/572
Co-authored-by: kjeremy <kjeremy@gmail.com>
Instead only opt-in to CallHierarchy since it has a vscode API but LSP support
is still proposed.
Discovered while working on SemanticTokens which does not have a vscode API
and is still in the proposed state. Somehow enabling it would crash the
language server.
See https://github.com/microsoft/vscode-languageserver-node/issues/572
