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 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.
These match the equivalent options in VSCode. `trim_trailing_whitespace`
is also the name used by EditorConfig.
* `trim-final-newlines` trims any extra line endings after the final one
* `trim-trailing-whitespace` trims any trailing whitespace (but not
empty lines)
Previously all register selection info boxes had "Registers" as the
title. That was particularly confusing for `copy_between_registers`
which presents two info boxes back-to-back.
Previously the `filter` caused the diagnostics to not be attached to the
document - which is good - but the out-of-date diagnostics were still
inserted into the global (editor-wide) diagnostic set. Instead we should
completely discard out-of-date diagnostics.
There is no functional change to the move - it's just moving the code
into helix-view under a new method `Editor::handle_lsp_diagnostics` -
thought there is a typo fix, the removal of an unnecessary clone (for
the document's language config) and the removal of some nesting.
Co-authored-by: Sofus Addington <sofus@addington.dk>
This will replace the `Sender<CompletionEvent>` in the child commits.
It tracks sender alongside extra metadata about the responses received
from providers - namely whether a request is incomplete or not - which
can be reused between subsequent requests to the provider.
Completions are not specific to LSP anymore. In the child commits we
will expand on the types in this module so this refactor is done
eagerly to minimize changes later.
Previously LSP notifications were sent within a future and most callers
used a `tokio::spawn` to send the notification, silently discarding any
failures like problems serializing parameters or sending on the channel.
It's possible that tokio could schedule futures out of intended order
though which could cause notifications where order is important, like
document synchronization, to become partially shuffled. This change
removes the future wrapper and logs all internal failures.
Also included in this commit is the same change for `Client::reply`
which was also unnecessarily wrapped in a future.
Co-authored-by: Pascal Kuthe <pascalkuthe@pm.me>
This matches the layout of `shell_impl_async` in `commands.rs` and
avoids a hang or maybe deadlock in `to_writer`'s calls to
`tokio::io::AsyncWriteExt::write_all`. I don't really understand the
underlying cause of the hang but it seems it's necessary to spawn a
new tokio task to provide input to stdin. This is shown in an example
in `tokio::process::Child::wait` but not documented explicitly.
This change refactors the DAP `Event` type, the `helix_dap` module and
the `helix_dap::transport` module to be closer to the equivalent
implementations in `helix_lsp`. The DAP `Event` type is similar to LSP's
`Notification` so this change rewrites the enum as a trait which is
implemented by empty types (for example `enum Initialized {}`).
`Event` is then reintroduced as an enum in `helix_dap` with a helper
function to convert from the `Event` as the transport knows it. By
separating the definitions of `Event` between lib and transport, we can
handle incoming events which are not known to our `Event` enum. For
example debugpy sends `"debugpySockets"` which is unknown. With this
change, unknown events are discarded with an info-level log message.
The `Request` type was already a trait but did not have an enum with the
known values. This change also introduces a `helix_dap::Request` enum
similar to `helix_dap::Event`. This resolves a TODO comment about
avoiding `unwrap` when parsing the request's arguments.
This seems to be a relic from the change which added external formatting
commands - initially it worked by writing the file in place and
reloading it. Now this error type is not possible and can be removed.
This should help debug formatting failures when using external
formatters in the future. Previously we didn't log anything when an
external formatter failed despite having a custom error type for it.
* feat: improve information on the amount of files loaded
* refactor: naming consitency Doc and not Buf
* fix: correct name of method
* chore: appease clippy
* feat: more human error information when Helix cannot start
* refatcor: use if guard on match arm
Terminals which support the enhanced keyboard protocol send events for
keys pressed with the Super modifier (Windows/Linux key or the Command
key). The only changes that are needed to support this in Helix are:
* Mapping the modifier from crossterm's KeyModifiers to Helix's
KeyModifiers.
* Representing and parsing the modifier from the KeyEvent text
representation.
* Documenting the ability to remap it.
When writing keybindings, use 'Meta-', 'Cmd-' or 'Win-' which are all
synonymous. For example:
[keys.normal]
Cmd-s = ":write"
will trigger for the Windows or Linux keys and the Command key plus 's'.
This should make it easier to figure out why the theme-check CI job
fails. Previously the message didn't include the failing key so you
were left searching or guessing where the error occurred.
This fixes reading from the clipboard when using the termcode provider.
Reading isn't implemented for the termcode provider so `get_contents`
returns `ClipboardError::ReadingNotSupported`. `read_from_clipboard`
needs to recognize this case and use the saved values instead of
emitting an error log and returning nothing.
Follow-up of #10839
Also see #12142
The configuration here is not super intuitive - in order to yank from
a clipboard provider we want it to paste the clipboard and in order to
paste to the clipboard we want it to yank the contents we pass.
This swaps the programs for yank and paste to align with that.
Ref #10839
