-
Notifications
You must be signed in to change notification settings - Fork 190
Fix shift selection in vi (insert) & emacs mode #927
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Thanks, that seems similar but clearer than the solution by Claude #911 . Noticed one minor issue, steps to reproduce:
|
Yeah, you're totally right; I missed this test case. Should be fixed now, all the modes seem to work for me. |
Your last commit didn't change anything in my setup. Say I have |
There's another complication: inconsistent behavior of selection in vi normal mode triggered by |
Okay I pushed up a commit that actually does fix it. My prior one did fix shift selection going leftwards but seems to have just shifted the issue to being present moving to the right for vi normal mode + cut operations. This new commit fixes it for both, but adds some complexity that I don't love. The core issue is that when we perform the cut operation, we immediately go into insert mode which then messes up the calculation for text to delete. Since we're in insert mode, it selects one character short even though the selection was made with vi normal mode. Let me know what you think of this. Also, I'm not sure exactly what you're referring to with:
From my experience, I can't even get the two to behave the same on a fresh build of the main branch. It seems that shift selection for vi normal mode has some other bug that makes it operate inconsistently with the cut and other operations. |
Yeah, probably rooted elsewhere. OMG... |
I used to take this issue to test AI agents' capabilities, haha. Never found one that's good enough. Claude 4.0 >> Gemini 2.5 pro on this issue, but still lame. |
Yeah since I'm new to this repo claude 4 has helped out with some of this but ultimately I'm having to babysit it pretty aggressively. Keeps wanting to implement hacky one-off fixes. |
Any movement on this? |
Bumping this. |
0b7721b
to
7047385
Compare
Rather than separate pub enum Selection {
Inclusive(usize),
Exclusive(usize),
}
pub struct Editor {
// ...
selection: Option<Selection>
// ...
} that way the anchor and mode will always have to be updated together. |
Forgot to stage
Good call! I've implemented it and retested with the suggestion. Let me know what you think. Sorry for the delay, I've been travelling the last few weeks and haven't had much free time. |
last_undo_behavior: UndoBehavior, | ||
selection_anchor: Option<usize>, | ||
selection: Option<Selection>, | ||
edit_mode: PromptEditMode, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good news, this one seems to be fixed by recent changes, with an itching edge case:
This makes me wonder, do we really need these boilerplates? Lines 23 to 99 in adeb8ea
I mean, entering selection and movements with selection should be logically different operations, while Shift + arrow keys just trigger them consecutively. |
Okay I updated the enum shape to be logically distinct. Noteably though this will require more than just a version bump in nushell as it changes the way we interface with the cursor. The changes are pretty small though: nushell/nushell@main...collinmurch:nushell:main Which would you prefer? Reverting to the old one with the coupled enum shape or this new one, which requires nushell changes? I'd like to get this bug fixed. I can look at the vi issue that's currently present perhaps after. |
src/enums.rs
Outdated
EditCommand::MoveLeftBefore { .. } => { | ||
write!(f, "MoveLeftBefore Value: <char>, Optional[select: <bool>]") | ||
} | ||
EditCommand::Move { movement, .. } => match movement { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for not making it clear, but this isn't what I meant:
- We probably don't need the bool to mark whether a cursor movement is triggered with selection.
- Instead, selection status should be a native property of the editor itself.
- In vi normal mode, press
v
to toggle selection on/off (inclusive selection) - In all modes, shift + arrow keys to firstly turn selection (exclusive) on, then handle the movement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's too much for this bug fixing PR, I'll leave it for other reviewers to judge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I got it. Yeah I hear you I can probably take a stab at this too and throw up a draft MR. Otherwise I'd probably fall back on the previous implementation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I got it. Yeah I hear you I can probably take a stab at this too and throw up a draft MR. Otherwise I'd probably fall back on the previous implementation
Yeah, I think reverting to previous implementation makes it easier to review.
It works well for me. The implementation looks not very straightforward but I guess we don't have much options without completely redesigning the code base of selection and movement with selection, which I'm afraid none of us has the passion to work on. We could use some TODO comments if we have the vision of a "better" design. After all, I know little about the reedline code, let's await for Bahex to make the call. |
Yeah agreed. I just want this darn issue fixed. I've been using my own fork of |
Thanks for all your work on this! |
This PR fixes shift selection in vi (insert) & emacs mode. The gist is that we were incorrectly selecitng an additional character when selecting leftwards (holding shift and pressing left arrow). One extra character to the right of the start location was getting highlighted and would be affected by any delete or other operations.
Tested on macOS with both vi & emacs mode. No regression of vi (normal) shift selection functionality.
Fix for this issue: #922 which I think is a duplicate of #893.