Repository navigation
Add opt-in click-to-jump-to-entry in multiple entry edit mode - #112
Merged
Merged
Conversation
Reworks PR #49 on the current dev branch. Adds an editor preference (off by default) that, in multiple entry edit mode, makes clicking an entry on the canvas set it as the current entry. Two fixes over the original PR: - The original passed the group-relative index straight to jumpToEntry, which targets the wrong module entry when the edited group does not start at index 0. Now maps through entries[indexInGroup].index. - The original read cursorState.position (only updated on mouse move), so a press without a preceding move did not jump. Now the click position is derived from the press event itself. The jump is gated on multiple entry edit mode (entries.size > 1); single edit mode is unaffected. Adds the preference field/default to AppConf, the preferences switch, strings for all four languages (en/zh/ja/ko), and direct tests for getEntryIndexByCursorPosition. The declarative switch is additionally covered by the existing PreferencesPagesTraversalTest. Co-Authored-By: RibosomeK <122797zhyktb@gmail.com> Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Jumping to the current entry is a no-op except that jumpToEntry always fires the auto-centering scroll (scrollFitViewModel.emitNext), so clicking the already-current entry re-centered the view unexpectedly. Guard the jump on the target index differing from the current index. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Clicking the current entry's left border (shared with the previous entry's end) switched the current entry to the previous one, because getEntryIndexByCursorPosition resolves a shared border to the first (left) entry. More generally, grabbing a border/point is a drag intent, not an entry-selection intent. Restrict the click-to-jump to presses that are not hovering a draggable point (i.e. clicks on an entry body), and extract the logic into maybeJumpToClickedEntry. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
sdercolin
added a commit
that referenced
this pull request
Jul 13, 2026
Reflects the features merged in #111 and #112 across all four READMEs (en/zh-CN/ja/ko): - Correct the parameter-line key action note: it is no longer limited to single entry editing mode. In multi-entry editing mode Q/W move the left/right border of the entry under the cursor, and the current-entry border actions can be bound in Keymaps. - Add the opt-in "Click to jump to entry" editor preference to the Multi-entry editing mode section. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
Reworks #49 (by @RibosomeK) on the current
devbranch.What it does
Adds an editor preference (off by default) that, in multiple entry edit mode, makes clicking an entry on the canvas set it as the current entry. Configurable under Preferences → Editor.
Fixes over the original PR
jumpToEntry, which targets the wrong module entry when the edited group doesn't start at index 0. This maps throughentries[indexInGroup].index(the real module index).cursorState.position, which is only updated on mouse-move, so a press without a preceding move didn't jump. The click position is now derived from the press event itself.The jump is gated on multiple entry edit mode (
entries.size > 1); single edit mode is unaffected.getEntryIndexByCursorPositionalready landed ondev(via #111), so it's reused rather than re-added.Changes
AppConf.Editor: newclickToJumpToEntryfield +DEFAULT_CLICK_TO_JUMP_TO_ENTRY = false.PreferencesPages: a switch in the Editor page (with description).Marker.kt: threadseditorState+screenRangeinto the cursor press handler and performs the jump.JumTo→JumpTotypo in the string key.Tests
getEntryIndexByCursorPosition(contained / shared-border / outside).PreferencesPagesTraversalTest(default value, serialization round-trip, field isolation).ktlintCheck+ the marker / preferences / strings suites pass.The click-in-canvas pointer handler itself is UI/native code and isn't unit-tested, but it's a thin wrapper over the tested primitive.
🤖 Generated with Claude Code