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] 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