This takes advantage of the synchronized output commands from crossterm
to tell the terminal emulator when to pause and resume drawing. This
should feel snappier and have fewer visual artifacts like tearing when
we update the screen with many changes (scrolling or changing theme for
example).
`cossterm::terminal::terminal_features` queries for all VT extension
features at once and gives back a small struct with the current state of
each feature. We can use this struct to determine which features the
terminal supports. This patch changes to prefer this feature over
individual queries like `supports_keyboard_enhancement` and
`query_terminal_theme_mode`.
This also updates our handling of the Kitty keyboard protocol. Once we
enable the protocol we ask the terminal for the currently enabled flags.
If we see that the terminal hasn't enabled the requested flags then we
turn off the feature. This is intended for Zellij which doesn't support
the `REPORT_ALTERNATE_KEYS` flag. When `DISAMBIGUATE_ESCAPE_CODES` is
enabled but not `REPORT_ALTERNATE_KEYS` we get key combinations like
`A-S-9` instead of `A-(` (which we also get without the enhanced
keyboard protocol). Disabling the protocol is simpler in this case than
normalizing based on the keyboard.
Historically we haven't wanted to add light/dark mode since it required
platform-specific dependencies. The Contour terminal [proposed] a VT
extension to query for the current mode and subscribe to future changes,
however, which can be supported squarely in Crossterm with no new deps.
Currently at least Contour, Kitty and Ghostty support this on the
terminal emulator side and Neovim on the client side.
This patch allows configuring multiple themes:
# this is still accepted:
# theme = "ayu_dark"
theme = { dark = "ayu_dark", light = "ayu_light" }
On startup we query the terminal for the current mode and choose that
theme. We then receive events from crossterm whenever the terminal
changes theme.
[proposed]: https://github.com/contour-terminal/contour/blob/master/docs/vt-extensions/color-palette-update-notifications.md
This fixes a regression from 6da1a79d80. `:buffer-close` on an
unmodified document would cause later panics since the document should
not have been removed. Instead of eagerly removing the document on the
first line we need to wait until we've checked that it's unmodified.
The point of ghost transactions is to avoid notifying language servers
about changes since the change is meant to be temporary. This is used
for completion while selecting items in the menu: updating the language
server would mess up incomplete completions.
When a document is changed by a ghost transaction the language server
will not be notified so its understanding of the document will not be
synchronized and any positions it sends may be out-of-date. So we should
avoid triggering a request for new document color information when a
document is changed by a ghost transaction.
Even though there is a check for `is_like_msvc`, when setting `CXX` to
`clang++` this will miss that check and try to use `-fPIC`, which is an
invlaid flag for the target.
Previously the `call` helper (and its related functions) returned a
`serde_json::Value` which was then decoded either later in the client
(see signature help and hover) or by the client's caller. This led to
some unnecessary boilerplate in the client:
let resp = self.call::<MyRequest>(params);
Some(async move { Ok(serde_json::from_value(resp.await?)?) })
and in the caller. It also allowed for mistakes with the types. The
workspace symbol request's calling code for example mistakenly decoded a
`lsp::WorkspaceSymbolResponse` as `Vec<lsp::SymbolInformation>` - one of
the untagged enum members (so it parsed successfully) but not the
correct type.
With this change, the `call` helper eagerly decodes the response to a
request as the `lsp::request::Request::Result` trait item. This is
similar to the old helper `request` (which has become redundant and has
been eliminated) but all work is done within the same async block which
avoids some awkward lifetimes. The return types of functions like
`Client::text_document_range_inlay_hints` are now more verbose but it is
no longer possible to accidentally decode as an incorrect type.
Additionally `Client::resolve_code_action` now uses the `call_with_ref`
helper to avoid an unnecessary clone.
This adds events for:
* a document being opened
* a document being closed
* a language server sending the initialized notification
* a language server exiting
and also moves some handling done for these scenarios into hooks,
generally moving more into helix-view. A hook is also added on
`DocumentDidChange` which sends the `text_document_did_change`
notification - this resolves a TODO in `document`.
This resolves a TODO in the core diagnostic module to refactor this
type. It was originally an alias of `LanguageServerId` for simplicity.
Refactoring as an enum is a necessary step towards introducing
"internal" diagnostics - diagnostics emitted by core features such as
a spell checker. Fully supporting this use-case will require further
larger changes to the diagnostic type, but the change to the provider
can be made first.
Note that `Copy` is not derived for `DiagnosticProvider` (as it was
previously because `LanguageServerId` is `Copy`). In the child commits
we will add the `identifier` used in LSP pull diagnostics which is a
string - not `Copy`.
This is the same change as 1c9a5bd366 but for:
* document symbols
* workspace symbols
* goto definition/declaration/.../references
* hover
Instead of bailing when one server fails, we log an error and continue
gathering items from the other responses.
When requesting code actions from multiple LSP servers,
rather than bailing as soon as an error is encountered,
instead log the error and then keep going so that successful
requests can be presented to the user.
This is purely for ergonomics: we should be able to pass strings for
example
crate::runtime_file(format!("namespace/{foo}/{bar}.txt"))
(Note that this works on Windows, see the `Path` documentation.)
This is a minor move that will make future refactors of code actions
simpler. We should be able to move nearly all code action functionality
into `helix-view`, save UI stuff like the `menu::Item` implementation
and dealings with the compositor.
Note that this injection doesn't work currently because precedence is
not handled by the current syntax highlighter. The switch to tree-house
will properly handle the precedence of this pattern.
