Draw a long reply to a couple of screens, with the rest a press away

Iris approved the cap and set the one exception: never the latest
response. That one is being read as it arrives, often still arriving, and
putting "show the rest" under the turn somebody is waiting for hides the
answer they are waiting for. Everything behind it is history, which is
what this is for.

The limit is on the **source**, not on the height, and that is the whole
point. Clipping a laid-out row to a height saves nothing -- Compose
measures the text and throws the overflow away, so the line-breaking has
already happened -- while cutting the string before it is parsed stops
the work being done at all, the parse included. Four thousand characters
is about two screenfuls, with a thousand of slack so that a reply barely
over the limit is not given a control worth nothing to anybody.

The cut is at a line ending, because a markdown source cut mid-line is a
different document: half a heading marker, a list item with no bullet, a
link whose closing bracket was dropped. A fence left open is closed,
which is the one case a line boundary does not cover -- an unterminated
``` swallows the rest of the reply into a code block, so the truncation
would change how the part still on screen is *drawn* rather than only how
much of it there is, and a reader cannot tell that from the reply
genuinely having been code. Verified against a reply whose cut lands
inside a 400-line Rust block: the block renders as a block, closes, and
the control sits below it in ordinary text.

`markdownIn` now names both forms, because which one a row draws is not
decided there -- so pressing the control is a cache hit rather than a
50ms parse on the frame it happens in, and neither form is a key that no
row ever looks up.

Measured on the emulator, now that it renders on the GPU and its frame
numbers mean something -- two flings over replies of the same size in the
same session, one capped and one not:

                       uncapped 62,310    capped 54,990 (4,000 drawn)
  janky (legacy)            58.20%              11.33%
  slow UI-thread frames          5                   1
  p50                         23ms                16ms
  p90                         30ms                24ms

The modern "Janky frames" figure is 4.04% against 3.59% -- near identical,
because both stay inside the compositor's deadline on this emulator. The
win is UI-thread work, which is what was aimed at, and the legacy metric
is the one that counts it.

Expanded is remembered by the screen, beside the other expansion sets, so
scrolling away and back does not shut something deliberately opened.

Known and not fixed: the floating jump-to-latest control is centred at the
bottom of the list and overlaps this one's label whenever a capped reply's
foot lands in that band. It is the overlay's pre-existing disregard for
content -- long replies have always had text under it -- but a control
there is worse than prose, and it is now common rather than incidental.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
irisandClaude Opus 5 committed 2026-08-31 00:19:20 -04:00
1 parent 0dc248b9e4
commit 592038aa54
3 files changed
+154 -4

No files matched your search

@@ -642,6 +642,10 @@ fun SessionScreen(settings: ServerSettings, summary: SessionSummary, onBack: ()
// by default, which is the rule for anything new in this transcript: a screen that opens
// everything it can is one nobody can scan.
var expandedNotes by remember { mutableStateOf(setOf<Long>()) }
// Long replies the reader has asked to see the rest of, by the seq of the row. Held here
// rather than in the row so that scrolling away and back does not shut something they
// deliberately opened -- the same reason the sets above it are here.
var expandedReplies by remember { mutableStateOf(setOf<Long>()) }
// Uploaded-but-not-yet-sent attachment ids; sent with the next message.
var pendingAttachments by remember { mutableStateOf(listOf<String>()) }
// What this session is set to now, seeded from the row that opened it and
@@ -722,6 +726,12 @@ fun SessionScreen(settings: ServerSettings, summary: SessionSummary, onBack: ()
// What is actually drawn: the transcript with runs of adjacent tool
// calls folded into one row each.
val rows = remember(items) { groupToolRuns(items) }
// The reply drawn whole however long it is; see the transcript list below. Recomputed with
// `items` rather than tracked as it arrives, because "newest" moves: a reply that was the
// last one becomes history the moment the next turn starts, and a row that kept its
// exemption after that would be the one enormous row this exists to bound.
val newestReply =
remember(items) { items.filterIsInstance<TranscriptItem.AssistantMsg>().lastOrNull()?.seq }
/**
* Everything the transcript list draws, from one event.
@@ -1580,8 +1590,37 @@ fun SessionScreen(settings: ServerSettings, summary: SessionSummary, onBack: ()
text = item.text,
images = item.images,
)
is TranscriptItem.AssistantMsg ->
AssistantMessage(item.text, replies)
is TranscriptItem.AssistantMsg -> {
// The newest reply is never cut. It is the one being read
// as it arrives -- often still arriving -- and putting a
// "show the rest" under a turn somebody is waiting for
// hides the answer they are waiting for. Every reply
// behind it is history, and history is what this is for.
val shortened =
if (
item.seq == newestReply ||
item.seq in expandedReplies
)
null
else remember(item.text) { shortenedReply(item.text) }
if (shortened == null) {
AssistantMessage(item.text, replies)
} else {
CappedReply(
full = item.text,
shortened = shortened,
replies = replies,
onShowMore = {
// Anchored like every other row that changes
// height, so the edge the reader touched
// stays where it is.
toggleAnchored(row.key, bounds, bounds.top) {
expandedReplies = expandedReplies + item.seq
}
},
)
}
}
is TranscriptItem.ToolRun ->
ToolCard(
tool = item,