Fix evil motion crossing into stale whitespace cells (#246)#250
Open
dakra wants to merge 1 commit into
Open
Conversation
c90bfa6 to
ab6b5d3
Compare
zsh's zle and prompt_toolkit redraw inline deletions by overwriting
with spaces rather than emitting CSI K, leaving the Emacs buffer with
trailing whitespace cells past the live end of input. evil's word
motion treated those cells as content and walked off the input row -
so 'word word word<esc>bbcw<esc>w' jumped to the next buffer line,
and the following 'dw' sent down-arrows through the PTY, triggering
zsh history navigation that scrubbed the input.
Clamp 'evil-forward-word-begin' / '-word-end' / '-WORD-begin' /
'-WORD-end', 'evil-end-of-line', 'evil-end-of-visual-line', and
'evil-last-non-blank' via a 'save-restriction' narrow whose upper
bound is the terminal cursor's buffer position. When point is past
the cursor (scrollback) the clamp is skipped so it can't cut point
out of the visible region.
Also fall back to readline C-a from 'evil-beginning-of-line' /
'evil-first-non-blank' when the cursor's row carries no
'ghostel-prompt' property - so '0' / '^' lands at input start even
when the shell isn't sourcing the OSC 133 integration.
'--sync-point-on-next-redraw' carries point to the new cursor.
Add 'evil-ghostel-send-and-follow' so user-defined normal-state
passthrough bindings can opt into the same redraw-time point sync;
the redraw advice deliberately preserves point in normal state to
keep column-only motions ('^', '$', '0') from being undone by
incidental redraws, which is the right default but blocks 'send
key, follow with point' use cases.
Fixes #246
7b9caef to
3bcb7ed
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes the operator misfires reported in #246 (and supersedes the diagnosis from #218):
Mechanism
zsh's zle and prompt_toolkit redraw inline deletions by overwriting with spaces rather than emitting CSI K. The deleted columns end up as real space characters in the Emacs buffer past the live end of input. evil's 'evil-forward-word-begin' treats those cells as content and walks off the input row to the next buffer line; the subsequent 'dw' from the wrong row sends down-arrows through the PTY, which zsh interprets as history-next, scrubbing the input.
The clamp narrows the buffer's upper bound to the cursor's buffer position before the motion runs. When point is past the cursor (scrollback) the narrow is skipped so it can't cut point out of the visible region.
Test plan
Out of scope