fix(editor): keep caret at end-of-line on Up/Down navigation#12674
Open
VictorVow wants to merge 1 commit into
Open
fix(editor): keep caret at end-of-line on Up/Down navigation#12674VictorVow wants to merge 1 commit into
VictorVow wants to merge 1 commit into
Conversation
Multi-line and cross-block Up/Down navigation lost end-of-line stickiness: from the end of a line the caret landed mid-line on a longer adjacent line (in the same block or the next/previous block) instead of staying at the end. The EOL-sticky behavior existed in the original newline-arithmetic implementation but was dropped in 237857a when Up/Down moved to pixel-position navigation (needed for soft-wrapped rows and proportional/wide glyphs). Restore it as a targeted guard rather than a revert: - Within a block (move-cursor-up-down): add a pure cursor/adjacent-line-end-pos helper; when the caret is at end-of-line, jump to the end of the adjacent hard line, otherwise fall back to the existing pixel navigation so soft-wrap and mid-line movement are unchanged. select-up-down is untouched. - Across blocks (move-cross-boundary-up-down): add a cursor/end-of-line? predicate (symmetric with beginning-of-line?) and pass an :end sentinel instead of the numeric column when the source caret is at end-of-line; text-range-by-lst-fst-line maps :end to the end of the target's last line (:up) or first line (:down). The numeric-pos path is unchanged, so mid-line up/down still preserves the column. Add frontend.util.cursor-test covering adjacent-line-end-pos (both directions, no-adjacent-line, single-line, land-at-end-regardless-of-length) and text-range-by-lst-fst-line (both directions, :end sentinel, numeric-pos non-regression).
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
1 participant
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
Details
cursor/end-of-line?predicate, symmetric with the existingbeginning-of-line?.handler/editor.cljsmove-cross-boundary-up-down→handler/block.cljstext-range-by-lst-fst-line): pass an:endsentinel when the source caret is at EOL, so it lands at the end of the adjacent block's edge line (last line for:up, first line for:down). The numeric-column path is unchanged.util/cursor.cljsmove-cursor-up-down): when at EOL, jump to the end of the adjacent hard line via the new pureadjacent-line-end-pos; otherwise fall back to the existing pixel/mock-text navigation, so soft-wrapped rows and mid-line movement are unchanged.select-up-downis untouched.Test plan
frontend.handler.block-test,frontend.util-test, and newfrontend.util.cursor-test— 12 tests / 74 assertions, 0 failures, 0 errors.clj-kondoclean on all changed files; node-test build compiles with 0 warnings.