| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
| |
This roughly matches the behavior of the diagnostic picker: when
jumping to a diagnostic with `[d`/`]d`/`[D`/`]D`, the range of the
diagnostic is selected instead of the start point.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Reset mode when changing buffers
This is similar to the change in
e4c9d4082a139aac3aea4506918171b96e81f5b9: reset the editor to normal
mode when changing buffers. Usually the editor is already in normal
mode but it's possible to setup insert-mode keybindings that change
buffers.
* Move normal mode entering code to Editor
This should be called internally in the Editor when changing documents
(Editor::switch) or changing focuses (Editor::focus).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* add command and keybding to jump to next/prev hunk
* add textobject for change
* Update helix-vcs/src/diff.rs
Co-authored-by: Michael Davis <mcarsondavis@gmail.com>
* select entire hunk instead of first char
* fix selection range
Co-authored-by: Michael Davis <mcarsondavis@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
* Add `View::ensure_cursor_in_view_center` to adjust view after searching and jumping
Also `offset_coodrs_to_in_view` was refactored to reduce duplicated position calculations.
* Fix a wrong offset calculation in `offset_coords_to_in_view_center`
It ignored `scrolloff` if `centering` is false.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Change default TS object bindings
Changes 'match inside/around' bindings for:
- type definition from `c` to `t`
- comments from `o` to `c`
- tests from `t` to `T`
Also changes those for the `]` / `[` bindings.
* Update docs for changed keybinds
Co-authored-by: Michael Davis <mcarsondavis@gmail.com>
|
| | |
|
| | |
|
| |
|
|
| |
This reverts commit fd00f3a70eb626242bb2fcc9bddf2c4d94580a9a.
|
| |
|
|
|
|
| |
This matches the insert-mode behavior for Vim and Kakoune: if the
current line is empty except for whitespace, `<ret>` should insert a
line ending at the beginning of the line, moving any indentation to the
next line.
|
| | |
|
| |
|
|
|
|
| |
View::apply should only be called by EditorView after
42e37a571e75aaf4feb1717dfebe8cf215e535dd. This change removes the
duplicate calls within undo/redo which could cause a panic.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Language Servers may signal that they do not support a method in
the initialization result (server capabilities). We can check these
when making LSP requests and hint in the status line when a method
is not supported by the server. This can also prevent crashes in
servers which assume that clients do not send requests for methods
which are disabled in the server capabilities.
There is an existing pattern the LSP client module where a method
returns `Option<impl Future<Output = Result<_>>>` with `None` signaling
no support in the server. This change extends this pattern to the rest
of the client functions. And we log an error to the statusline for
manually triggered LSP calls which return `None`.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, jumplists could grow unchecked. Every transaction is
applied to jumplist selections to ensure that they are up to date
and within document bounds, so this would cause every edit to become
more expensive as jumplist lengths increased throughout a session.
Setting a maximum number of entries limits the cost.
Vim and Neovim limit their jumplists:
* https://github.com/vim/vim/blob/b298fe6cbae3b240b10dbd55d9c38d0cc8e033d3/src/structs.h#L141
* https://github.com/neovim/neovim/blob/e8cc489accc435076afb4fdf89778b64f0a48473/src/nvim/mark_defs.h#L57
Notably, Kakoune does not. In Kakoune, changes are applied to jumplist
entries lazily as you hit `<C-o>`/`<C-i>` though, so Kakoune doesn't
have the same growing cost concerns. Kakoune also does not have a
concept of a View which limits the cost further.
Vim and Neovim limit to 100. This seems unreasonably high to me so I've
set this to 30 to start. We can increase if this is problematically
low.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
d6323b7cbc21a9d3ba29738c76581dad93f9f415 changed the behavior of paste
to select the newly inserted text. This is preferrable in normal mode
because it's useful to be able to act on the new text. This behavior
is worse for insert or select mode though:
* In insert mode, the cursor ends up on the last character of the newly
selected text, so further typing inserts text before the last
character.
* In select mode, the current selection is replaced with the new text
selection which doesn't extend the current selection. With this
change, the selection is extended to include the new text.
This aligns the behavior more closely with Kakoune, but it's
coincidental instead of intentional: Kakoune doesn't implement
bracketed paste (AFAIK) which causes this behavior in insert mode,
and Kakoune doesn't have a select mode.
|
| | |
|
| |
|
|
|
| |
Previously, commands such as `r<tab>` (replace with tab) or `t<tab>`
(select till tab) had no effect. This is because `KeyCode::Tab` needs
special treatment (like `KeyCode::Enter`).
|
| |
|
| |
Co-authored-by: Austen Adler <agadler@austenadler.com>
|
| |
|
|
|
|
|
|
|
| |
PR #4134 switched the autocomplete menu from alphabetical to fuzzy
sorting. This commit removes the still existing filtering by prefix and
should enable full fuzzy sorting of the autocomplete menu.
closes #3084, #1807
Co-authored-by: Blaž Hrastnik <blaz@mxxn.io>
|
| |
|
|
|
| |
The text within the command palette used a custom format to display
the keybinding for a command. This change switches to the key sequence
format that we use for pending keys and macros.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
* Add command to add word boundaries to search
* Calculate string capacity before building
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* dynamically resize line number gutter width
* removing digits lower-bound, permitting spacer
* removing max line num char limit; adding notes; qualified successors; notes
* updating tests to use new line number width when testing views
* linenr width based on document line count
* using min width of 2 so line numbers relative is useful
* lint rolling; removing unnecessary type parameter lifetime
* merge change resolution
* reformat code
* rename row_styler to style; add int_log resource
* adding spacer to gutters default; updating book config entry
* adding view.inner_height(), swap for loop for iterator
* reverting change of current! to view! now that doc is not needed
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
| |
|
|
|
| |
The sequence "_y"_p panics because the blackhole register contains an
empty values vec. This causes a panic when pasting since it unwraps
a `slice::last`.
|
| |
|
|
|
|
|
|
|
| |
This follows changes in Kakoune to the same effects:
* p/<space>p: https://github.com/mawww/kakoune/commit/266d1c37d0d970a7eff747f5e6a5773a3cea39d8
* !/<A-!>: https://github.com/mawww/kakoune/commit/85b78dda2e29d70b620836b04224b104426bdbae
Selecting the new data inserted by shell or pasting is often more
useful than retaining a selection of the pre-paste/insert content.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
When backward-deleting a character, if this character and the following
character form a Pair, we want to delete both. However, there is a bug
that deletes both characters also if both characters are closers of some
Pair.
This commit fixes that by adding an additional check that the deleted
character should be an opener in a Pair.
Closes https://github.com/helix-editor/helix/issues/4544.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Before:
Goto next buffer. [buffer-next]
After:
Goto next buffer. [:buffer-next]
|
| |
|
| |
Co-authored-by: Michael Davis <mcarsondavis@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bug occurs on `shell_insert_output` and `shell_append_output`
commands.
The previous implementation would create a child process using the Rust
stdlib's `Command` builder. However, when nothing should be piped in
from the editor, the default value for `stdin` would be used. According
to the Rust stdlib documentation that is `Stdio::inherit` which will
make the child process inherit the parent process' stdin. This would
cause the terminal to freeze.
This change will set the child process' stdin to `Stdio::null` whenever
it doesn't pipe it. In the `if` statement where this change was made
there was an extra condition for windows that I am not sure if would
require some special treatment.
|
| |
|
|
|
|
| |
This complicates the code a little but it often divides by two the number of allocations done by
the functions. LSP labels especially can easily be called dozens of time in a single menu popup,
when listing references for example.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we do auto formatting, the code that takes the LSP's response and applies
the changes to the document are just getting the currently focused view and
giving that to the function, basically always assuming that the document that
we're applying the change to is in focus, and not in a background view.
This is usually fine for a single view, even if it's a buffer in the
background, because it's still the same view and the selection will get updated
accordingly for when you switch back to it. But it's obviously a problem for
when there are multiple views, because if you don't have the target document in
focus, it will ask the document to update the wrong view, hence the crash.
The problem with this is picking which view to apply any selection change to.
In the absence of any more data points on the views themselves, we simply pick
the first view associated with the document we are saving.
|
| | |
|
| | |
|
| | |
|
| | |
|
