From 5b1121be16b9fef94668595dab5ace97ca2f4d0d Mon Sep 17 00:00:00 2001 From: iris <2+iris@noreply.localhost> Date: Thu, 3 Sep 2026 21:15:15 -0400 Subject: [PATCH 1/3] Take the card's tap back off the words, and let the words still be selected Verified on the emulator with all three gestures on an opened peer message: a tap on its words shuts it, a press held past the long-press timeout selects from them, and the tap that puts that selection away does only that. The earlier note in TODO.md saying markdown inside these cards could not be selected was a coordinate error on my part -- the presses were landing in the card's bottom padding, below the last line -- and it is removed rather than carried forward. Co-Authored-By: Claude Opus 5 --- TODO.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/TODO.md b/TODO.md index ab249fe..d7c0f7d 100644 --- a/TODO.md +++ b/TODO.md @@ -13,11 +13,6 @@ one in place when it turns out to need a decision. (`AiAppSelectionColors`), which took the fill from #5B4C73 to #776394 on that surface. Worth confirming this was the complaint rather than a selection that draws *nothing* on the phone. -- [ ] Text inside an opened peer message or memory note cannot be selected at - all — the heading of the same card can, and so can a tool call's output, - so it is the markdown text specifically. Pre-existing (measured against - the build before this session's changes, by stashing them). It - contradicts AGENTS.md's "all transcript text is selectable". - [ ] Messages received from other agents are inconsistent — sometimes they appear, sometimes they don't. **Needs a rig.** Read the code rather than measured: a live Claude session only learns of a peer message from the From aa6d9b256e974fa8b01b15ce5f8293b11bd1fc17 Mon Sep 17 00:00:00 2001 From: iris <2+iris@noreply.localhost> Date: Thu, 3 Sep 2026 21:19:27 -0400 Subject: [PATCH 2/3] Let a selection show through an inline code chip Selecting a sentence highlighted every word of it except the ones in backticks. An inline span's background is part of the text's own drawing and the selection rectangle is drawn underneath it, so an opaque chip hid the selection completely -- and there is no way to draw it over instead, since the order is the text node's. The chip's fill is 60% now: measured on the emulator, unselected it is #161622 against a #1E1E2E page, so it is still a clear step down, and selected it moves to #3C344F, which is the whole point. This is what Iris's screenshot was showing. A fenced block was never affected -- its background is on the box around the text rather than on spans, so the selection lands on top of it, which is why it looked fine when I went looking. Co-Authored-By: Claude Opus 5 --- TODO.md | 8 -------- .../main/kotlin/com/example/aiapp/Markdown.kt | 19 ++++++++++++++++++- 2 files changed, 18 insertions(+), 9 deletions(-) diff --git a/TODO.md b/TODO.md index d7c0f7d..f3789b0 100644 --- a/TODO.md +++ b/TODO.md @@ -5,14 +5,6 @@ one in place when it turns out to need a decision. ## App — transcript -- [ ] Text inside code blocks does not highlight when selected. **Measured, and - it does** — the selection is drawn, but over the near-black surface a code - block and a tool's output sit on, Material's default 40%-alpha tint - composites to a barely-there smudge, much weaker than the same selection - over a reply. The app now states its own selection colours - (`AiAppSelectionColors`), which took the fill from #5B4C73 to #776394 on - that surface. Worth confirming this was the complaint rather than a - selection that draws *nothing* on the phone. - [ ] Messages received from other agents are inconsistent — sometimes they appear, sometimes they don't. **Needs a rig.** Read the code rather than measured: a live Claude session only learns of a peer message from the diff --git a/app/androidApp/src/main/kotlin/com/example/aiapp/Markdown.kt b/app/androidApp/src/main/kotlin/com/example/aiapp/Markdown.kt index 82ad370..20a1b80 100644 --- a/app/androidApp/src/main/kotlin/com/example/aiapp/Markdown.kt +++ b/app/androidApp/src/main/kotlin/com/example/aiapp/Markdown.kt @@ -368,7 +368,15 @@ private fun MarkdownRoot( // exactly a card's own fill, so a fenced block inside a tool call had no // background at all and one in a reply read as a step *up* out of the page. codeBackground = rawSurface, - inlineCodeBackground = rawSurface, + // The same colour, but let through. An inline span's background is part of the + // *text's* own drawing and the selection rectangle is drawn underneath it, so an + // opaque chip hides the selection completely: selecting a sentence highlighted + // every word of it except the ones in backticks, which is a difference in + // appearance the reader has no way to account for. Translucent, the selection + // shows through and the chip still reads as one step down from the page -- there + // is no way to draw it over the selection instead, since the order is the text + // node's. + inlineCodeBackground = rawSurface.copy(alpha = INLINE_CODE_ALPHA), // The same tint a code block gets, rather than the renderer's 2%-alpha default: // two adjacent tints that differ by a fiftieth read as one flat block on a phone, // so the table would have had a border-less grid and nothing saying where it began. @@ -711,3 +719,12 @@ class ParsedReplies { ready.clear() } } + +/** + * How much of the inline-code chip's fill is its own colour, the rest being whatever it sits on. + * + * High enough that the chip is still a clear step down from the page, low enough that a selection + * under it changes what the chip looks like. Both halves are the point: at 1.0 the chip was the + * only part of a selected sentence that did not look selected. + */ +private const val INLINE_CODE_ALPHA = 0.6f From 9c4df43951c27178848dd541bf78c18cf2c70c2a Mon Sep 17 00:00:00 2001 From: iris <2+iris@noreply.localhost> Date: Thu, 3 Sep 2026 21:19:51 -0400 Subject: [PATCH 3/3] Record why autocompact cannot be handed to a driver yet Co-Authored-By: Claude Opus 5 --- TODO.md | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/TODO.md b/TODO.md index f3789b0..1f9dcde 100644 --- a/TODO.md +++ b/TODO.md @@ -19,10 +19,17 @@ one in place when it turns out to need a decision. ## Session settings - [ ] Autocompact belongs in session settings; empty disables it, which is the - default. **Needs a decision before building** — nothing called autocompact - exists yet on either side. `PLAN.md` has it only as a planned pi-driver - feature (`set_auto_compaction`), and Claude Code runs its own. So this is - a new server feature, and the open questions are what the empty-or-not - value *is* (a token count? a percentage of the context window?) and which - drivers it applies to. + default. Iris chose "hand it to the driver" — only where a driver has + auto-compaction of its own. **That option was offered on a false premise + and is not buildable yet.** It named pi's `set_auto_compaction`, but pi + was never built as a driver here: `session/llama.rs` talks to + `llama-server`'s OpenAI-compatible endpoint directly, and its `compact()` + refuses outright. Claude Code's auto-compaction is the CLI's own and + nothing in the stream-json control protocol this app uses configures it. + So the setting would be stored, passed to a driver, refused by every one + of them, and the field would never appear on any session. What is needed + first is either a driver that can take it, or a different rule — the + server watching `contextTokens` and running `/compact` itself is the one + that would work today, for Claude sessions, and it is the option that was + not chosen.