The clipboard special registers are able to retain multiple selections
and also join the value when copying it to the clipboard. So by default
we should yank regularly to the '*' and '+' registers. That will have
the same behavior for the clipboards but will allow pasting multiple
selections if the clipboard doesn't change between yanks.
Since the clipboard provider now lives on the Registers type, we want
to eliminate it from the Editor. We can do that and clean up the
commands that interact with the clipboard by calling regular yank,
paste and replace impls on the clipboard special registers.
Eventually the clipboard commands could be removed once macro keybinding
is supported.
This fixes a discrepancy between regular registers which are used for
yanking multiple values (for example via `"ay`) and regular registers
that store a history of values (for example `"a*`).
Previously, the preview shown in `select_register`'s infobox would show
the oldest value in history. It's intuitive and useful to see the most
recent value pushed to the history though.
We cannot simply switch the preview line from `values.first()`
to `values.last()`: that would fix the preview for registers
used for history but break the preview for registers used to yank
multiple values. We could push to the beginning of the values with
`Registers::push` but this is wasteful from a performance perspective.
Instead we can have `Registers::read` return an iterator that
returns elements in the reverse order and reverse the values in
`Register::write`. This effectively means that `push` adds elements to
the beginning of the register's values. For the sake of the preview, we
can switch to `values.last()` and that is then correct for both usage-
styles. This also needs a change to call-sites that read the latest
history value to switch from `last` to `first`.
This is an unfortunately noisy change: we need to update virtually all
callsites that access the registers. For reads this means passing in the
Editor and for writes this means handling potential failure when we
can't write to a clipboard register.
This removes a handful of allocations for functions calling into the
function, which is nice because the prompt may call this function on
every keypress.
Pascal and I discussed this and we think it's generally better to
take a 'RopeSlice' rather than a '&Rope'. The code block rendering
function in the markdown component module is a good example for how
this can be useful: we can remove an allocation of a rope and instead
directly turn a '&str' into a 'RopeSlice' which is very cheap.
A change to prefer 'RopeSlice' to '&Rope' whenever the rope isn't
modified would be nice, but it would be a very large diff (around 500+
500-). Starting off with just the syntax functions seems like a nice
middle-ground, and we can remove a Rope allocation because of it.
Co-authored-by: Pascal Kuthe <pascal.kuthe@semimod.de>
Since regex is almost always injected into other languages,
`pattern_character`s will inherit the highlight for the structure that
injects them (for example `/foo/` in JavaScript or `~r/foo/` in Elixir).
This removes the string highlight when used in the prompt.
We also add `ERROR` node highlighting so that errors in regex syntax
appear in the prompt. This resolves a TODO in the `regex_prompt`
function about highlighting errors in the regex.
We can use tree-sitter-regex highlighting in prompts for entering
regexes, like `search` or `global_search`. The `highlighted_code_block`
function from the markdown component makes this a very small change.
This could be improved in the future by leaving the parsed syntax tree
on the prompt, allowing incremental updates. Prompt lines are usually so
short though and tree-sitter-regex is rather small and uncomplicated,
so that improvement probably wouldn't make a big difference.
* Add initial support for LSP DidChangeWatchedFiles
* Move file event Handler to helix-lsp
* Simplify file event handling
* Refactor file event handling
* Block on future within LSP file event handler
* Fully qualify uses of the file_event::Handler type
* Rename ops field to options
* Revert newline removal from helix-view/Cargo.toml
* Ensure file event Handler is cleaned up when lsp client is shutdown
* _apply_motion generalization where possible
API encourages users to not forget setting `editor.last_motion` when
applying a motion. But also not setting `last_motion` without applying a
motion first.
* (rename) will_find_char -> find_char
method name makes it sound like it would be returning a boolean.
* use _apply_motion in find_char
Feature that falls out from this is that repetitions of t,T,f,F are
saved with the context extention/move and count. (Not defaulting to extend
by 1 count).
* Finalize apply_motion API
last_motion is now a private field and can only be set by calling
Editor.apply_motion(). Removing need (and possibility) of writing:
`motion(editor); editor.last_motion = motion`
Now it's just: `editor.apply_motion(motion)`
* editor.last_message: rm Box wrap around Arc
* Use pre-existing `Direction` rather than custom `SearchDirection`.
* `LastMotion` type alias for `Option<Arc<dyn Fn(&mut Editor)>>`
* Take motion rather than cloning it.
Co-authored-by: Michael Davis <mcarsondavis@gmail.com>
* last_motion as Option<Motion>.
* Use `Box` over `Arc` for `last_motion`.
---------
Co-authored-by: Michael Davis <mcarsondavis@gmail.com>
The spec explicitly disallows publishDiagnostic to be sent before
the initialize response:
> ... the server is not allowed to send any requests or notifications to
> the client until it has responded with an InitializeResult ...
(https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#initialize)
But if a non-compliant server sends this we currently panic because we
'.expect()' the server capabilities to be known to fetch the position
encoding. Instead of panicking we can discard the notification and log
the non-compliant behavior.
Merges the code for the Picker and FilePicker into a single Picker that
can show a file preview if a preview callback is provided. This change
was mainly made to facilitate refactoring out a simple skeleton of a
picker that does not do any filtering to be reused in a normal Picker
and a DynamicPicker (see #5714; in particular [mikes-comment] and
[gokuls-comment]).
The crux of the issue is that a picker maintains a list of predefined
options (eg. list of files in the directory) and (re-)filters them every
time the picker prompt changes, while a dynamic picker (eg. interactive
global search, #4687) recalculates the full list of options on every
prompt change. Using a filtering picker to drive a dynamic picker hence
does duplicate work of filtering thousands of matches for no reason. It
could also cause problems like interfering with the regex pattern in the
global search.
I tried to directly extract a PickerBase to be reused in Picker and
FilePicker and DynamicPicker, but the problem is that DynamicPicker is
actually a DynamicFilePicker (i.e. it can preview file contents) which
means we would need PickerBase, Picker, FilePicker, DynamicPicker and
DynamicFilePicker and then another way of sharing the previewing code
between a FilePicker and a DynamicFilePicker. By merging Picker and
FilePicker into Picker, we only need PickerBase, Picker and
DynamicPicker.
[gokuls-comment]: https://github.com/helix-editor/helix/issues/5714#issuecomment-1410949578
[mikes-comment]: https://github.com/helix-editor/helix/issues/5714#issuecomment-1407451963
Resolves issue #6888 by adding a command to join all selections and yank
them to the specified register. The typed command takes an argument as
the separator to use when joining the selections.
Previously a count or register selection would be lost while opening
the command palette. This change allows using a register selection or
count in any command chosen from the command palette.
Previously the register selection (via `"`) would be lost in the middle
of any key sequence longer than one key. For example, `<space>f` would
clear the register selection after the `<space>` making it inaccessible
for the `file_picker` command.
This behavior does not currently have any effect in the default keymap
but might affect custom keymaps. This change aligns the behavior of the
register with count. Making this change allows propagating the register
to the `command_palette` (see the child commit) or other pickers should
we decide to use registers in those in the future. (Interactive global
search for example.)
Does not change any behavior other than making the tuple slightly
more idiomatic. Keymap infobox shows key events, then the respective
description. This commit makes sure that order is used from the get go,
rather than flipping it midway.
* chore: avoid format! call with argument when useless
* feat: also clear diagnostics for unopened documents when exiting an LSP
* feat: we already worked on `self.editor.diagnostics` no need to redo the checks
* Add command for merging non-consecutive ranges
* Add `merge_selections` command to book
* Simplify `merge_ranges`
Heeded the advice of @the-mikedavis to stop iterating over all ranges and simply merge the first and the last range, as the invariants of `Selection` guarantee that the list of ranges is always sorted and never empty.
* Clarify doc comment of `merge_ranges`
* Add `helix_lsp::client::Client::supports_feature(&self, LanguageServerFeature)`
* Extend `doc.language_servers_with_feature` to use this method as filter as well
* Add macro `language_server_with_feature!` to reduce boilerplate for non-mergeable language server requests (like goto-definition)
* Refactored most of the `find_map` code to use the either the macro or filter directly via `doc.language_servers_with_feature`
Michael Davis
Philipp Mildenberger
dependabot[bot]
Ryan Fowler
sigmaSd
Pascal Kuthe
Alex Vinyals
Jonathan
Tudyx
Yomain
Gabriel Hansson
Alberto Romero
Gokul Soumya
spectre256
Alex
A-Walrus
Zisulin Morbrot
Robert
0xHiro / ヒロ
Luca Schlecker
vwkd
Ethan Wilkes
Matthew Toohey
Poliorcetics
Szabin