mirror of
https://github.com/storytold/gridcraft.git
synced 2026-10-31 06:06:48 -06:00
While a formula reference is being pointed from the keyboard, Ctrl+arrow (⌘arrow on a Mac) moved the pointed cell by one, and Ctrl+Shift+arrow extended the pointed range by one cell, so `=COUNTIF(`, a click on the top of a column and ⌘⇧↓ pointed at two cells instead of the column of data. Both now go to the edge of the data region, as the same keys do on the selection outside an edit: `point_move` takes `jump` and uses the engine's `selection::jump`, which Ctrl+arrow on the grid already uses, so the two agree (last filled cell of a run, else the next filled cell, else the sheet edge). A pointed range that reaches the sheet edge is written as whole columns or rows (`A:B`), as Excel writes it. The editor used to read Shift from `i.modifiers`, the modifier state when the frame's input was collected; an arrow pressed and released within one frame (a control client's `ui.key`, an automation tool's keystroke) had already lost it. It now reads the modifiers carried by the arrow's own key event, as the grid's keyboard handler does. Test: ctrl_arrows_in_point_mode_jump_to_the_edge_of_the_data (down to the last filled cell, right across the data, down to the sheet edge, Ctrl+Up without Shift to the next filled cell, then a plain arrow). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>