| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
ref: https://github.com/helix-editor/helix/issues/2245
ref: https://github.com/helix-editor/helix/pull/4545
Co-authored-by: sireliah <sajuukk@gmail.com>
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The current test DSL currently has no way to express being at the end of
a line, save for putting an explicit LF or CRLF inside the `#[|]#`. The
problem with this approach is that it can add unintended extra new lines
if used in conjunction with raw strings, which insert newlines for you.
This is a simple attempt to mitigate this problem. If there is an
explicit newline character at the end of the selection, and then it
is immediately followed by the same newline character at the right end
of the selection, this following newline is removed. This way, one can
express a cursor at the end of a line explicitly.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Example:
```
test
testitem
```
Select line 2 with x, then type Alt-C; Helix will go into an infinite
loop. The saturating_sub keeps the head_row and anchor_row pinned at 0,
and a selection is never made since the first line is too short.
|
| |
|
|
|
|
|
|
| |
`:write` and other file-saving commands now check the file modification
time before writing to protect against overwriting external changes.
Co-authored-by: Gustavo Noronha Silva <gustavo@noronha.dev.br>
Co-authored-by: LeoniePhiline <22329650+LeoniePhiline@users.noreply.github.com>
Co-authored-by: Pascal Kuthe <pascal.kuthe@semimod.de>
|
| | |
|
| |
|
|
| |
selected (#5288)
|
| |
|
|
|
|
| |
The 'revisions' field on History can't be treated as linear: each
Revision in the revisions Vec has a parent link and an optional child
link. We can follow those to unroll the recent history.
|
| |
|
|
|
|
|
|
| |
When using undo/redo, the history revision can be decremented. In that
case we should apply the inversions since the given revision in
History::changes_since. This prevents panics with jumplist operations
when a session uses undo/redo to move the jumplist selection outside
of the document.
|
| |
|
|
|
|
|
| |
This case panics since undo/redo call View::apply and here, the edit
that moves the jumplist selection out-of-bounds is not yet applied when
View::apply is called in undo/redo. View::apply should only be called
by the EditorView now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
d6323b7cbc21a9d3ba29738c76581dad93f9f415 introduced a regression for
shell commands like `|`, `!`, and `<A-!>` which caused the new
selections to be incorrect. This caused a panic when piping (`|`)
would cause the new range to extend past the document end.
The paste version of this bug was fixed in
48a3965ab43718ce2a49724cbcc294b04c328b81.
This change also inherits the direction of the new range from the old
range and adds integration tests to ensure that the behavior isn't
broken in the future.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix range offsets in multi-selection paste
d6323b7cbc21a9d3ba29738c76581dad93f9f415 introduced a regression with
multi-selection paste where pasting would not adjust the ranges
correctly. To fix it, we need to track the total number of characters
inserted in each changed selection and use that offset to slide each
new range forwards.
* Inherit selection directions on paste
* Add an integration-test for multi-selection pasting
|
| |
|
| |
Co-authored-by: Michael Davis <mcarsondavis@gmail.com>
|
| |
|
|
|
|
| |
When force quitting, we need to block on the pending writes to ensure
that write commands succeed before exiting, and also to avoid a crash
when all the views are gone before the auto format call returns from
the LS.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Make sure buffer-close waits for the document to finish its writes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix backwards selection duplication widening bug
* Add integration tests
* Make tests line-ending agnostic
Make tests line-ending agnostic
Use indoc to fix tests
Fix line-ending on test input
|
| | |
|
| |
|
|
|
|
|
|
|
| |
During write-quit, if the file fails to be written for any reason, helix
will still quit without saving the changes. This fixes this behavior by
introducing fallibility to the asynchronous job queues. This will also
benefit all contexts which may depend on these job queues.
Fixes #1575
|
| | |
|
| | |
|
| |
|
