Skip to content
C.W.K.
Stream
Lesson 03 of 06 · published

Selection Follows the Text

~11 min · selection, mouse, synchronized-output, paste, swiftterm

Level 0Spark
0 XP0/48 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete

A Selection Is a Promise About Text

The pane-tree lesson said selection copies text from the view, not a scraped grid, because the pane is an object. That is true, and in September 2026 it turned out to be the start of the work rather than the end. When you drag across a terminal, you are not choosing cells. You are choosing words, and you expect them to be the words you get when you let go. A terminal whose selection stays on the cells while the words move under it has broken that promise, even though every cell it copies is perfectly real.

One Drag, Two Owners

A drag inside a pane has two possible owners. A program that asked for mouse reporting — tmux, a full-screen editor, a TUI — wants the drag itself: tmux uses it to move a pane border. Smolder's own selection wants it too. The rule now is short: an unmodified drag goes to the program, including a remote tmux border; a Shift-drag is the local selection. In the embedded core, one switch quietly does two jobs. While mouse reporting is allowed, every new chunk of output clears the selection, and only while it is allowed does the scroll wheel reach a program that tracks the mouse.

The first fix lowered that switch permanently so selections would survive streaming output. The wheel stopped reaching tmux and editors, and the wheel regression tests sat red for a day before anyone looked. The current shape: the switch rests on; each live-output feed lowers it just long enough for the bytes to land without clearing a Shift-drag; a gesture Smolder keeps lowers it until mouse-up. A mouse change now runs the wheel tests too.

Harnesses Redraw; They Do Not Scroll

Then Dad dragged across a coding harness and watched his selection slide through the transcript. Claude Code and Grok do not scroll the terminal. They redraw the whole alternate screen, row by row, inside synchronized-output frames (the ?2026 mode), so the transcript moves while the screen never scrolls. The embedded core moves a selection only on a real scroll, so the highlighted cells stayed put and new words flowed through them.

The selection follower runs on every live chunk and watches for those frames. It never judges inside an open one — a half-drawn frame matches nothing. After each chunk, once no frame is open, it checks whether the selected text still sits under the selection. If the text has moved nearby, the selection moves with it, whether a frame drew it there or not. If the text is gone, it matters how it went: after a framed redraw the selection is dropped, because its words left the screen; when a program like top rewrote numbers in place without a frame, the selection stays where it was and follows the new text from there. Copy-on-select had already taken the text at mouse-up; the follower keeps what you see honest about what you took.

Paste Belongs to the Operator Too

The same weeks widened explicit paste. A multiline paste used to require a verified local shell prompt; coding CLIs and remote SSH programs that turn on bracketed-paste mode now accept it too, because the program itself declared it can tell a paste from typing. The preview still checks that the target has not changed, still rejects terminal control sequences, and still never adds Enter. This is the operator's hand on the clipboard — a different path from Pippa's proposals, which keep their own stricter rule.

Owning the pane includes owning what a selection means. Give drags to the program unless the operator holds Shift, follow selected text through redraws without ever judging inside an open frame, and let explicit paste reach any program that declared bracketed paste — never with an Enter.

Code

Who gets the mouse, and when a selection moves·text
drag without modifier      -> the program (mouse reporting): tmux border, editor, TUI
Shift-drag                 -> Smolder's local selection
scroll wheel               -> the program, when it tracks the mouse

the core's one switch ("allow mouse reporting")
  on  : wheel reaches the program, BUT every output feed clears the selection
  off : selection survives, BUT the wheel never reaches the program
  Smolder: rests ON; lowered per live feed; lowered for a kept gesture until mouse-up

harness redraw (Claude Code, Grok)
  ESC[?2026h ... rows rewritten ... ESC[?2026l     (no scroll happens)
  after each live chunk, once no frame is open (never mid-frame):
    text moved nearby          -> move the selection onto it (framed or not)
    text gone, a frame redrew  -> drop the selection (copy already happened at mouse-up)
    text gone, rewritten in place without a frame (top, htop) -> selection stays

explicit paste (operator)
  multiline allowed when the program enabled bracketed paste
  target re-checked, control sequences rejected, never appends Enter

External links

Exercise

Open a full-screen program that streams (a coding CLI, a log viewer, a monitor). Select a word while it is updating. Write what happens to your highlight and to what you copy. Then decide, for that program, which drag should belong to the program and which to the terminal, and write the rule in one sentence.
Hint
If the highlight stays on cells while words pass through, the program redraws instead of scrolling. If the wheel stops working when you fix it, you lowered the wrong switch.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign in — Please sign in to comment.

No comments yet — be the first.