aboutsummaryrefslogtreecommitdiff
path: root/editors/code/package.json
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* Fail Travis on Prettier formatting issueAlan Du2019-01-151-1/+1
|
* :arrow_up: npmAleksey Kladov2019-01-131-3/+3
|
* Allow user to set path to ra_lsp_server in vscode settingsgentoo902019-01-051-0/+7
|
* index stuff produced by macrosAleksey Kladov2019-01-031-1/+1
|
* named multiline problem patterns are not parsed properly in vscode at the momentBernardo2019-01-011-2/+29
|
* fix regex and add rustc-watch problem matcherBernardo2019-01-011-23/+32
|
* Support tracing lsp requests.DJMcNab2018-12-201-0/+11
| | | | | | TODO: Debug why decorations are sent even when highlightingOn is disabled This makes the log volume so high its impossible to work with anyway
* use new clear-terminal featureAleksey Kladov2018-12-151-2/+2
|
* remove direct dep on event-stream: malisious version was unpublishedAleksey Kladov2018-12-091-1/+0
|
* Add package command and upgrade event-streamDJMcNab2018-12-081-1/+2
|
* Run npm update and add private and preview flagsDJMcNab2018-12-081-7/+9
| | | | | | | | Private stops npm publish working, which would be nonsensical anyway In case it gets added to the vscode extension repository, preview marks it as such Private may also prevent publishing to the vscode extension repository
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-25 05:48:56 +0000