[HLfromZ]

When a stacked candidate panel moves above the caret near the bottom of the screen, the first candidate remains at the top and becomes the farthest candidate from the input position.

Add optional style/vertical_auto_reverse, using the same setting name as Weasel, to keep the first candidate nearest the caret. It defaults to false and also supports color-scheme overrides.

Configuration

In squirrel.custom.yaml:

patch:
  style/candidate_list_layout: stacked
  style/text_orientation: horizontal
  style/vertical_auto_reverse: true

With the option enabled, the visual order from top to bottom is 1, 2, 3… below the caret and …3, 2, 1 above it.

Behavior

• Applies to stacked candidates with horizontal text; linear, vertical-text and fullscreen layouts retain their existing order.
• Keeps original candidate indices, labels, comments, highlights and mouse selection. Non-inline preedit stays at the top of the panel.
• Plain Up/Down, including keypad arrows, follow visual order when reversed. Modified shortcuts and other keys keep their original keycodes.
• Measures the final panel placement and performs one bounded relayout when the direction changes, before displaying the panel.

The first commit contains the feature; the second adds a standalone regression harness and its instructions.

Validation

• Universal Release build (arm64 and x86_64) with Xcode 27 beta on macOS 27.
• SwiftLint and Periphery completed without errors. Existing warnings remain in rimeUpdate, the Periphery configuration and ReservedProperty.empty.
• bash tests/vertical-auto-reverse.sh: 225 assertions passed on one connected display. It exercises production AppKit/TextKit layout, config loading, hit testing and key mapping with an isolated Rime configuration and a controller stub.
• Inspected rendered normal, reversed, non-inline-preedit and wrapped-candidate panels.
• Installed the local Apple Silicon build and manually confirmed automatic reversal works in actual use.

[LEOYoon-Tsaw]

I have serious doubt that this should not be such a big diff. The feature seems simple enough

[HLfromZ]

I have serious doubt that this should not be such a big diff. The feature seems simple enough

Most of the code is new tests, and they can be deleted if not needed.