Show placeholder while run command gets runnables from server
This PR fixes a UI annoyance in the VS Code extension when working in large codebases where rust-analyzer can take a few moments to interact with the server. Scenario:
1. Invoke "rust-analyzer: Run" from the command palette or hotkey
2. Quickly start typing to filter the list (or press Enter to accept the last runnable)
We often do this quickly from muscle memory without waiting to see the picker. The picker often takes several seconds to come up, causing us to type garbage into the currently open editor.
Fix:
Show a placeholder item before we call out to the server.
Selecting this item does nothing so if the user accidentally hits Enter nothing happens.
The list is populated and the placeholder dismissed when the actual runnables are retrieved. From here the behavior is the same as before.
editor/code: add option to suppress error notifications
Fixes https://github.com/rust-lang/rust-analyzer/issues/14193
- Added the `rust-analyzer.showRequestFailedErrorNotification` configuration option, which defaults to `true`
- If `rust-analyzer.showRequestFailedErrorNotification` is set to `true`, the current behavior is preserved.
- If `rust-analyzer.showRequestFailedErrorNotification` is set to `false`, no error toasts will be displayed for any of the failed requests caused by panics in r-a. This _only_ applies to events that are triggered "implicitly", such as `textDocument/hover`.
To test this, you can manually introduce a panic in one of the language server LSP handlers for non-command events. I added an explicit `panic!()` in the `textDocument/hover` event handler:
#### `rust-analyzer.showRequestFailedErrorNotification` set to `true` (default)
[2023-11-07 17-17-48.webm](https://github.com/rust-lang/rust-analyzer/assets/1665677/d0408ab8-79d1-42cf-a4e7-94e99d9783ec)
#### `rust-analyzer.showRequestFailedErrorNotification` set to `false`
[2023-11-07 17-16-49.webm](https://github.com/rust-lang/rust-analyzer/assets/1665677/0496d8d0-fb53-4bc6-a279-1a47f412dbdb)
Displaying local instead of web docs can have many benefits:
- the web version may have different features enabled than locally selected
- the standard library may be a different version than is available online
- the user may not be online and therefore cannot access the web documentation
- the documentation may not be available online at all, for example because it
is for a new feature in a library the user is currently developing
If the documentation is not available locally, the extension still falls back to
the web version.
According to the VS Code documentation, the vscode.open command opens the URL
_in the editor_ (https://code.visualstudio.com/api/references/commands).
However, in reality, it seems to do so only for file:// URLs, falling back to
other applications for other URL schemes (at least for HTTP/HTTPS).
Until now, the URL to the documentation was always HTTP based, so using the
vscode.open command was perfectly fine. However, displaying local documentation
will be supported from now on (see next commit). Local documentation is not
HTTP-based, but instead addressed via a file:// URL. The file URL would
therefore be opened in VS Code instead of in the browser — this is definitely
not what the user wants.
Therefore, the vscode.env.openExternal function is used instead, this function
never opens the URL in VS Code.
Increase the buffer size for discover project command
The default value for maxBuffer is 1 MiB[1]. If the discover project command returns stdout or stderr that is greater than 1 MiB, the extension would error with "RangeError: stderr maxBuffer length exceeded".
Set the default value for maxBuffer to 10 MiB for project discovery.
[1] https://nodejs.org/api/child_process.html#child_processexeccommand-options-callback
The default value for maxBuffer is 1 MiB[1]. If the discover project
command returns stdout or stderr that is greater than 1 MiB, the
extension would error with "RangeError: stderr maxBuffer length
exceeded".
Set the default value for maxBuffer to 10 MiB for project discovery.
[1] https://nodejs.org/api/child_process.html#child_processexeccommand-options-callback
Use the warning color when rust-analyzer is stopped
If the rust-analyzer server isn't running, we can't do much. Treat this state as a warning color, so it's more obvious.
Previously, clicking 'rust-analyzer' would stop the server
entirely. This was easy to do accidentally, and then the user has to
wait for the server to start up again.
