Thin the app's comments
The same pass the server had, on the Kotlin side: comments restating what the code says are gone, and the ones recording a measurement, a constraint or an incident are kept but cut to a few lines each. 6540 comment lines to 5674, and 920 lines off the app. Two doc comments had drifted onto the item above the one they describe -- `contextAfter`'s onto `sessionWorking` in Events.kt, and `UsageMonitor`'s equivalent on the server was fixed in the previous commit. Each is back on its own item, which is the only non-comment line this diff moves. The comments are reflowed to the column limit at their own indentation: several were written wide, and ktfmt re-wrapped them into lines holding a single orphan word. `/tmp` script, not kept -- ktfmt is idempotent over the result, which is the check. Left alone deliberately: this codebase's remaining comment density is high because the comments carry things the code cannot say -- what a null means, what a number was measured against, which bug a guard exists for. Of the 238 one-line doc comments in the app, five were pure restatement of the name and were removed; the rest each say something the signature does not. ktfmtFormat, compileDebugKotlin, lintDebug and testDebugUnitTest pass; cargo test (127), clippy --all-targets and fmt still clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
1 parent
79682f03a7
commit
edc39c7371
68 files changed
+2077
-2997
No files matched your search
@@ -34,22 +34,18 @@ import org.intellij.markdown.flavours.gfm.GFMTokenTypes
|
||||
*
|
||||
* The point is the draw phase and the lazy list. A reply's display list holds every glyph of it and
|
||||
* is re-recorded whenever drawing is invalidated, so one long message costs as much to draw as a
|
||||
* hundred short ones; and the list composes an item whole in the frame it scrolls into, so an item
|
||||
* has to be bounded for the worst frame to be. Measured on a Pixel 9 Pro XL, the tallest row still
|
||||
* being drawn was 36,982px, twenty-five screens in one message. A piece is a paragraph, a fence, a
|
||||
* table, one bullet: bounded, so both costs are.
|
||||
* hundred short ones; and the list composes an item whole in the frame it scrolls into. Measured on
|
||||
* a Pixel 9 Pro XL, the tallest row still being drawn was 36,982px -- twenty-five screens in one
|
||||
* message. A piece is a paragraph, a fence, a table, one bullet: bounded, so both costs are.
|
||||
*
|
||||
* Cut where the parser says the blocks are, which is the whole reason this is safe: a fence, a
|
||||
* table and a nested list are each one node whatever is inside them, so nothing is ever split down
|
||||
* the middle. A list is the one block that is not bounded -- a reply's list of sources can be forty
|
||||
* items -- so it is cut once more, into its items, and a nested list stays inside the item that
|
||||
* holds it.
|
||||
* Cut where the parser says the blocks are, which is what makes it safe: a fence, a table and a
|
||||
* nested list are each one node whatever is inside them. A list is the one block that is not
|
||||
* bounded -- a reply's list of sources can be forty items -- so it is cut once more, into its
|
||||
* items.
|
||||
*
|
||||
* A piece is an *address* into the message's one parse ([block] indexes the root's children, [item]
|
||||
* the list items of that child) rather than a substring of the message. Every piece of a message is
|
||||
* drawn from the same tree, so a message is parsed once however many pieces it is drawn as, and a
|
||||
* reference definition at its foot still resolves the links above it -- the two costs of cutting a
|
||||
* message into strings and parsing each on its own.
|
||||
* A piece is an *address* into the message's one parse rather than a substring of it. Every piece
|
||||
* is drawn from the same tree, so a message is parsed once however many pieces it is drawn as, and
|
||||
* a reference definition at its foot still resolves the links above it.
|
||||
*/
|
||||
@Immutable
|
||||
data class Piece(val block: Int, val item: Int = WHOLE_BLOCK) {
|
||||
@@ -59,8 +55,7 @@ data class Piece(val block: Int, val item: Int = WHOLE_BLOCK) {
|
||||
}
|
||||
|
||||
/**
|
||||
* The pieces of [parse], in reading order. Blank nodes between blocks -- the parser keeps the
|
||||
* newlines -- are not pieces.
|
||||
* The pieces of [parse], in reading order. Blank nodes between blocks are not pieces.
|
||||
*
|
||||
* A parse that failed yields one piece, so [MarkdownPiece] can still say what the message was: a
|
||||
* message that drew as nothing would be a hole in the transcript with no sign of what fell out.
|
||||
@@ -90,17 +85,15 @@ fun gapBefore(previous: Piece?, piece: Piece): Dp =
|
||||
val BLOCK_SPACING: Dp = 6.dp
|
||||
|
||||
/**
|
||||
* [piece] of [parse], drawn. Must be inside [MarkdownRoot] for the parse, which is what carries the
|
||||
* theme, the components and the reference links to the renderer's element composables.
|
||||
* [piece] of [parse], drawn. Must be inside [MarkdownRoot] for the parse, which carries the theme,
|
||||
* the components and the reference links to the renderer's element composables.
|
||||
*
|
||||
* A whole block goes to the renderer's own dispatch with this app's component table, so a paragraph
|
||||
* or heading is a [LinkedText], a table is [LinkedTableRow]s, and a nested list comes back here
|
||||
* through [MarkdownList]. Only the list item is drawn directly, because a list item is the one
|
||||
* piece the renderer has no element for.
|
||||
* A whole block goes to the renderer's own dispatch with this app's component table. Only the list
|
||||
* item is drawn directly, because a list item is the one piece the renderer has no element for.
|
||||
*
|
||||
* [continuesList] and [listContinues] are for a list cut across the segments of a live reply (see
|
||||
* `LiveParse`): an item that is the first or last of its own parse but not of the list the reader
|
||||
* sees keeps an inner item's padding, so nothing moves when the seam between segments does.
|
||||
* [continuesList] and [listContinues] are for a list cut across the segments of a live reply: an
|
||||
* item that is the first or last of its own parse but not of the list the reader sees keeps an
|
||||
* inner item's padding, so nothing moves when the seam between segments does.
|
||||
*/
|
||||
@Composable
|
||||
fun MarkdownPiece(
|
||||
@@ -112,8 +105,8 @@ fun MarkdownPiece(
|
||||
listContinues: Boolean = false,
|
||||
) {
|
||||
if (parse !is State.Success) {
|
||||
// The parser threw. Nothing else in the app has seen this happen; if it does, the words
|
||||
// are still worth more than a blank.
|
||||
// The parser threw. Nothing else in the app has seen this happen; if it does, the words are
|
||||
// still worth more than a blank.
|
||||
Text(text, modifier, style = MaterialTheme.typography.bodyLarge)
|
||||
return
|
||||
}
|
||||
@@ -144,8 +137,7 @@ fun MarkdownPiece(
|
||||
|
||||
/**
|
||||
* A whole list, for the places the renderer's dispatch reaches one it cannot hand to a piece: a
|
||||
* list inside a quote, and the nested lists an item holds. Top-level lists never come here; they
|
||||
* are drawn an item at a time as pieces.
|
||||
* list inside a quote, and the nested lists an item holds. Top-level lists never come here.
|
||||
*/
|
||||
@Composable
|
||||
fun MarkdownList(content: String, list: ASTNode, depth: Int, modifier: Modifier = Modifier) {
|
||||
@@ -170,9 +162,8 @@ fun MarkdownList(content: String, list: ASTNode, depth: Int, modifier: Modifier
|
||||
* list drawn as pieces looks exactly like one drawn whole. The list's own padding goes on its first
|
||||
* and last items, since there is no list column to carry it.
|
||||
*
|
||||
* The marker is the renderer's bullet and number, and a checkbox for a task item. It is drawn here
|
||||
* rather than by a handler because it is the thing a reader might one day want styled -- a
|
||||
* different glyph per depth, a colour -- and this is the one place it is drawn.
|
||||
* The marker is drawn here rather than by a handler because it is the thing a reader might one day
|
||||
* want styled -- a different glyph per depth, a colour -- and this is the one place it is drawn.
|
||||
*/
|
||||
@Composable
|
||||
private fun MarkdownListItem(
|
||||
@@ -231,8 +222,8 @@ private fun Marker(text: String, style: TextStyle) {
|
||||
/**
|
||||
* The bullet at each depth, cycling past the third: a disc, a ring, a square -- the ladder a
|
||||
* browser draws, so a nested list is told from its parent by the glyph as well as by the indent.
|
||||
* Checked on the emulator's system fonts, which is what makes them safe to rely on; a glyph the
|
||||
* platform lacks draws as a box, and that check is the price of adding one here.
|
||||
* Checked on the emulator's system fonts; a glyph the platform lacks draws as a box, and that check
|
||||
* is the price of adding one here.
|
||||
*/
|
||||
private val BULLETS = listOf("• ", "◦ ", "▪ ")
|
||||
|
||||
|
||||
Reference in new issue
Block a user