aboutsummaryrefslogtreecommitdiff
path: root/editors/code/package.json
Commit message (Collapse)AuthorAgeFilesLines
...
* Merge #1614bors[bot]2019-07-291-1/+1
|\ | | | | | | | | | | | | | | 1614: show prettier diff on CI r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * show prettier diff on CIAleksey Kladov2019-07-291-1/+1
| |
* | :arrow_up: npmAleksey Kladov2019-07-291-6/+6
|/
* Show type decoratorsKirill Bulatov2019-07-251-0/+14
|
* try to show exact prettier problemAleksey Kladov2019-07-251-1/+1
|
* :arrow_up: npm depsAleksey Kladov2019-07-251-1/+1
|
* Remove obsolete keybindingAleksey Kladov2019-07-211-5/+0
|
* underline mutable bindingsAleksey Kladov2019-07-191-3/+3
|
* highlight mutable variables differentlyEkaterina Babshukova2019-07-181-0/+9
|
* Update vsce to latestkjeremy2019-07-031-1/+1
|
* Run VS Code tests on CIRyan Cumming2019-06-291-1/+1
| | | | | | | | | | | | | This is actually much faster than I expected; it takes about 13 seconds to download VS Code and run the unit tests. This means the VS Code tests are still significantly faster than the Rust ones. If this ends up being unreliable we can always remove it later or move it to a separate optional job. We also need to ignore the `.vscode-test` directory when running `prettier` or it will get upset about some temporary JSON files VS Code creates.
* Initial Visual Studio Code unit testsRyan Cumming2019-06-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As promised in #1439 this is an initial attempt at unit testing the VSCode extension. There are two separate parts to this: getting the test framework working and unit testing the code in #1439. The test framework nearly intact from the VSCode extension generator. The main thing missing was `test/index.ts` which acts as an entry point for Mocha. This was simply copied back in. I also needed to open the test VSCode instance inside a workspace as our file URI generation depends on a workspace being open. There are two ways to run the test framework: 1. Opening the extension's source in VSCode, pressing F5 and selecting the "Extensions Test" debug target. 2. Closing all copies of VSCode and running `npm test`. This is started from the command line but actually opens a temporary VSCode window to host the tests. This doesn't attempt to wire this up to CI. That requires running a headless X11 server which is a bit daunting. I'll assess the difficulty of that in a follow-up branch. This PR is at least helpful for local development without having to induce errors on a Rust project. For the actual tests this uses snapshots of `rustc` output from a real Rust project captured from the command line. Except for extracting the `message` object and reformatting they're copied verbatim into fixture JSON files. Only four different types of diagnostics are tested but they represent the main combinations of code actions and related information possible. They can be considered the happy path tests; as we encounter corner-cases we can introduce new tests fixtures.
* Fix code after "apply suggestions"Aleksei Sidorov2019-06-241-2/+2
|
* Apply suggestions from code reviewAleksey Sidorov2019-06-241-2/+2
| | | Co-Authored-By: Aleksey Kladov <[email protected]>
* Introduce cargo-watch.check-commandAleksei Sidorov2019-06-241-1/+6
|
* make LRU cache configurableAleksey Kladov2019-06-121-0/+5
|
* Make rainbows optionalPascal Hertleif2019-05-271-0/+5
|
* Semantic highlighting spikePascal Hertleif2019-05-271-0/+2
| | | | | | | | | | 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?
* Improve highlighting of name refsLaurențiu Nicola2019-05-231-1/+46
|
* Address feedbackLaurențiu Nicola2019-05-211-28/+19
|
* Use ThemeColor and add support for light themesLaurențiu Nicola2019-05-211-0/+119
|
* switch to official extend selection APIAleksey Kladov2019-04-211-5/+0
|
* :arrow_up: codeAleksey Kladov2019-04-211-10/+10
|
* start cargo watch if not started interactivelyBernardo2019-04-191-1/+1
|
* recover rustc-watch problemMatchersBernardo2019-04-191-0/+12
|
* cargo watch start and stop commandsBernardo2019-04-191-1/+11
|
* Adds "restart server" commandRoberto Vidal2019-04-161-0/+5
|
* Add cargo-watch.check-argumentsEdwin Cheng2019-04-021-0/+10
|
* Add config for cargo-watch traceEdwin Cheng2019-04-021-0/+11
|
* Add proper process teminate methodEdwin Cheng2019-04-021-2/+3
|
* Improve cargo-watch usageEdwin Cheng2019-04-021-12/+0
|
* Change enableCargoWatchOnStartup to have three statesVille Penttinen2019-03-211-3/+13
| | | | | | | 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.
* Guard auto cargo watch behind a config optionIgor Matuszewski2019-03-181-0/+5
|
* activate extension if Cargo.toml is presentAleksey Kladov2019-03-131-1/+2
|
* prettier formatBernardo2019-03-101-1/+1
|
* simplify watch patternsBernardo2019-03-101-3/+3
|
* Add showWorkspaceLoadedNotification to vscode clientVille Penttinen2019-03-061-0/+5
| | | | | | | | | 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.
* Add vscode support for range in SyntaxTreeParamsVille Penttinen2019-03-031-1/+1
| | | | | | 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.
* Change default value of highlightingOn to falseVille Penttinen2019-02-261-1/+1
|
* Use named multiline Problem Matcherkjeremy2019-02-181-29/+2
| | | | | Now that https://github.com/Microsoft/vscode/pull/65840 is in the latest release we can use the first commit from https://github.com/rust-analyzer/rust-analyzer/pull/408
* Specify vscode 1.31kjeremy2019-02-121-1/+1
|
* Update dependenciesDJMcNab2019-02-101-2/+2
|
* Add support for a seperate output channel for trace messagesDJMcNab2019-02-101-1/+1
|
* Update npm packageskjeremy2019-02-071-7/+7
|
* Add new configuration "enableEnhancedTyping" to control registering of ↵Ville Penttinen2019-02-071-0/+5
| | | | | | | | | | | | | | | | | | "type" command 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.
* Add category to the commandsDJMcNab2019-01-291-8/+16
|
* Start the extension when rust-analyzer status is runDJMcNab2019-01-291-1/+3
|
* align command namingAleksey Kladov2019-01-281-25/+25
|
* add gc requestAleksey Kladov2019-01-251-0/+4
|
* ad status commandAleksey Kladov2019-01-221-0/+4
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-18 14:35:05 +0000