| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* _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>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Previously this was hard-coded to UTF-8 but we might have negotiated
another position encoding.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
When Picker and FilePicker are merged, not all Pickers will be able to
show a preview.
Co-authored-by: Gokul Soumya <gokulps15@gmail.com>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
(#7322)
|
| | |
|
| |
|
|
| |
Signed-off-by: Luca Schlecker <luca.schlecker@hotmail.com>
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.)
|
| | |
|
| | |
|
| |
|
|
| |
The plan is let `Keymaps` simply store `KeyTrie`s, as the `Keymap(Keytrie)` wrapping serves little to no purpose.
|
| |
|
|
| |
`keymap.name` is only used internally.
|
| |
|
|
|
| |
This makes it easier later control the order in which the key events
are presented.
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
Exist under the wrong (possibly just outdated) assumption that command
descriptions are written with their `KeyTrie` name prefixed
|
| | |
|
| | |
|
| |
|
|
| |
The variant Sequence is technically also a leaf.
|
| | |
|
| | |
|
| | |
|
| | |
|
