| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
| |
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`.
|
|
|
|
|
| |
These snippets use hardcoded registers but it can be useful to be able
to specify a register for these commands.
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* _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>
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
When Picker and FilePicker are merged, not all Pickers will be able to
show a preview.
Co-authored-by: Gokul Soumya <gokulps15@gmail.com>
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* 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`
|
| |
|
|
|
|
|
|
|
|
|
| |
`doc.language_servers_with_feature`
* 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`
|
|
|
|
| |
multiple language servers (code-action, completion, symbol pickers)
|
|
|
|
| |
Co-authored-by: Pascal Kuthe <pascal.kuthe@semimod.de>
|
| |
|
|
|
|
|
|
| |
return an iterator and refactor LanguageServerFeature handling to a HashMap (language server name maps to features)
Co-authored-by: Pascal Kuthe <pascal.kuthe@semimod.de>
|
|
|
|
| |
Co-authored-by: Pascal Kuthe <pascal.kuthe@semimod.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Language Servers are now configured in a separate table in `languages.toml`:
```toml
[langauge-server.mylang-lsp]
command = "mylang-lsp"
args = ["--stdio"]
config = { provideFormatter = true }
[language-server.efm-lsp-prettier]
command = "efm-langserver"
[language-server.efm-lsp-prettier.config]
documentFormatting = true
languages = { typescript = [ { formatCommand ="prettier --stdin-filepath ${INPUT}", formatStdin = true } ] }
```
The language server for a language is configured like this (`typescript-language-server` is configured by default):
```toml
[[language]]
name = "typescript"
language-servers = [ { name = "efm-lsp-prettier", only-features = [ "format" ] }, "typescript-language-server" ]
```
or equivalent:
```toml
[[language]]
name = "typescript"
language-servers = [ { name = "typescript-language-server", except-features = [ "format" ] }, "efm-lsp-prettier" ]
```
Each requested LSP feature is priorized in the order of the `language-servers` array.
For example the first `goto-definition` supported language server (in this case `typescript-language-server`) will be taken for the relevant LSP request (command `goto_definition`).
If no `except-features` or `only-features` is given all features for the language server are enabled, as long as the language server supports these. If it doesn't the next language server which supports the feature is tried.
The list of supported features are:
- `format`
- `goto-definition`
- `goto-declaration`
- `goto-type-definition`
- `goto-reference`
- `goto-implementation`
- `signature-help`
- `hover`
- `document-highlight`
- `completion`
- `code-action`
- `workspace-command`
- `document-symbols`
- `workspace-symbols`
- `diagnostics`
- `rename-symbol`
- `inlay-hints`
Another side-effect/difference that comes with this PR, is that only one language server instance is started if different languages use the same language server.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, when forward deleting (`delete_char_forward` bound to `del`,
`delete_word_forward`, `kill_to_line_end`) the cursor is moved to the
left in append mode (or generally when the cursor is at the end of the
selection). For example in a document `|abc|def` (|indicates selection)
if enter append mode the cursor is moved to `c` and the selection
becomes: `|abcd|ef`. When deleting forward (`del`) `d` is deleted. The
expectation would be that the selection doesn't shrink so that `del`
again deletes `e` and then `f`. This would look as follows:
`|abcd|ef`
`|abce|f`
`|abcf|`
`|abc |`
This is inline with how other editors like kakoune work.
However, helix currently moves the selection backwards leading to the
following behavior:
`|abcd|ef`
`|abc|ef`
`|ab|ef`
`ef`
This means that `delete_char_forward` essentially acts like
`delete_char_backward` after deleting the first character in append
mode.
To fix the problem the cursor must be moved to the right while deleting
forward (first fix in this commit). Furthermore, when the EOF char is
reached a newline char must be inserted (just like when entering
appendmode) to prevent the cursor from moving to the right
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some deletion operations (especially those that use indentation)
can generate overlapping deletion ranges when using multiple cursors.
To fix that problem a new `Transaction::delete` and
`Transaction:delete_by_selection` function were added. These functions
merge overlapping deletion ranges instead of generating an invalid
transaction. This merging of changes is only possible for deletions
and not for other changes and therefore require its own function.
The function has been used in all commands that currently delete
text by using `Transaction::change_by_selection`.
|
|
|
|
|
|
|
| |
When re requesting a completion that already has a selected item we
reuse that selections savepoint. However, the selection has likely
changed since that savepoint which requires us to use the selection
from that savepoint
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
Closes #6836
|
|
|
| |
Co-authored-by: Esra Fokker <esra.fokker@finalist.nl>
|
| |
|
| |
|
|
|
|
|
|
| |
fix typo
Co-authored-by: LeoniePhiline <22329650+LeoniePhiline@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
|
| |
fixup documentation
Co-authored-by: LeoniePhiline <22329650+LeoniePhiline@users.noreply.github.com>
fixup typo
Co-authored-by: LeoniePhiline <22329650+LeoniePhiline@users.noreply.github.com>
|
| |
|
|
|
|
|
|
| |
While scrolling (with the `scroll`) command scrolloff was calculated
slightly differently than in `ensure_cursor_in_view` which could cause
the cursor to get stuck while scrolling
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Virtual text lines (either caused by softwrapped inlay hints that take
multiple or line annotations) currently block scrolling downwards.
if the visual offset passed to char_idx_at_visual_offset or
visual_offset_from_block is within a virtual text line then the char
position before the virtual text and a visual offset are returned.
We previously ignored that visual offset and as a result the cursor
would be stuck at the start of the virtual text. This commit fixes
that by simply moving the cursor to the next char (so past the virtual
text) if this visual offset is non-zero
|