[fornwall]

Selecting a span of blank cells or whitespace between OSC 133 semantic boundaries could pull in neighboring prompt text and reverse the selection endpoints. The whitespace trims iterate with a CellIterator bounded by the end pin, but the iterator bounds only the row, so the trim ran past the end column into the next prompt.

To reproduce: Run this script and triple-click either blank cell between x and m on the first row. Before the fix, the selection reaches into the neighboring prompt text; after the fix, nothing is selected (like triple-clicking a blank row).

#!/bin/sh
# On exit:
# \033]133;C\007  Switch back to command-output mode (OSC 133;C).
# \033[?1049l     Leave the alternate screen and restore the original screen.
trap 'printf "\033]133;C\007\033[?1049l"' 0

# \033[?1049h     Enter the alternate screen, preserving the original screen.
# \033]133;C\007  Mark subsequent text as command output (OSC 133;C).
# \033[2J        Clear the visible screen, leaving unwritten output cells.
# \033[H         Move the cursor to the top-left corner.
printf '\033[?1049h\033]133;C\007\033[2J\033[H'

# \033]133;A\007  Mark the start of a prompt (OSC 133;A).
# x              Print a prompt cell in column 1.
# \033[2C        Move right two columns, leaving two unwritten output cells.
# m              Print another prompt cell in column 4.
# \033]133;C\007  Switch back to command-output mode (OSC 133;C).
printf '\033]133;A\007x\033[2Cm\033]133;C\007'

# Wait for Enter while you test selection; the exit trap restores the screen.
read -r _

AI disclosure: Initially created with the help of gpt-6 astra in codex. Iterated on, reviewed and tested by me.