Skip to main content

max / goingson

Say the task table's duplicate description resolves by deletion, not a generator build.rs's TASK_COLUMNS serves the JS task list only: the narrowing CSS, tables.columns.json and the index.html heading check. It deletes at the flip with the JS, so the overlap with src/quasi/task_list.rs's COLUMNS is the port's own shape and resolves by subtraction. The header finding proposed a build script emitting a Rust const for this module to include!; that is permanent machinery for keeping a retiring frontend in agreement with its replacement, and it is not being built. Comments and one test name. No behaviour change.
Co-Authored-By
Claude Opus 5 (1M context) <noreply@anthropic.com>
Author: Max Johnson <me@maxj.phd> · 2026-08-16 16:54 UTC
Signed with PGP, not checked
Commit: 70b97c933432fb6bd6e77fa914868bdf150751ae
Parent: 696071e
3 files changed, +28 insertions, -19 deletions
M src-tauri/build.rs +7
@@ -19,6 +19,13 @@
19 19 /// table is ordered is a runtime fact that changes when a header is pressed, so
20 20 /// a build script cannot hold it; `tasks-filter.js` writes it onto the heading
21 21 /// as `aria-sort`, which is the same field said in the webview's idiom.
22 + ///
23 + /// This serves the JS task list and nothing else, so it deletes at the flip
24 + /// along with `tasks.js` and the hand-written table in `index.html`. The
25 + /// described table lives in `src/quasi/task_list.rs` and is the one that
26 + /// survives. Until the flip a column added here has to be added there by hand;
27 + /// nothing checks that they agree and nothing is going to, because keeping the
28 + /// two in step is not work worth automating for a frontend being removed.
22 29 const TASK_COLUMNS: &[Column<'static>] = &[
23 30 // Without it the row does not identify itself.
24 31 Column {
M src-tauri/src/quasi/task_list.rs +17 -15
@@ -47,15 +47,17 @@
47 47 //!
48 48 //! # Findings
49 49 //!
50 - //! **1. The column description exists twice, in two vocabularies.** `build.rs`
51 - //! holds `TASK_COLUMNS` as `makeover_layout::Column` and emits the narrowing CSS
52 - //! and the JSON the frontend tests check themselves against; [`COLUMNS`] here
53 - //! holds the same seven columns as `quasi_router::screen::Column` because the
54 - //! runtime one carries an address and the build-time one cannot. The two agree
55 - //! today and nothing checks that they do. Not a vocabulary gap — the overlap is
56 - //! name, width and priority, which a build script could emit as a Rust const for
57 - //! this module to take the address half onto. Left alone because inventing that
58 - //! generator while porting the screen is two changes wearing one commit.
50 + //! **1. The column description exists twice, in two vocabularies, until the
51 + //! flip.** `build.rs` holds `TASK_COLUMNS` as `makeover_layout::Column` and
52 + //! emits the narrowing CSS and the JSON the frontend tests check themselves
53 + //! against; [`COLUMNS`] here holds the same seven as
54 + //! `quasi_router::screen::Column`, because the runtime one carries an address
55 + //! and the build-time one cannot. Not a vocabulary gap, and not a thing to fix:
56 + //! `TASK_COLUMNS` serves the JS task list only and deletes with it, so the
57 + //! duplication resolves by subtraction. Nothing checks that the two agree and
58 + //! nothing should — a generator bridging them, or a test asserting parity,
59 + //! would be permanent machinery in service of a frontend being removed. Add a
60 + //! column in both by hand in the meantime.
59 61 //!
60 62 //! **2. A table cannot say there is more.** [`Node::List`] carries a
61 63 //! [`Rest`](quasi_router::screen::Rest) and `Node::Table` carries nothing of the
@@ -155,12 +157,12 @@
155 157
156 158 /// The table, left to right.
157 159 ///
158 - /// The same seven columns as `build.rs`'s `TASK_COLUMNS`, in the same order,
159 - /// with the same widths and the same four marked sortable — see finding 1 above
160 - /// for why the description exists in two places and what would close it. The
161 - /// priority a column has when room runs out is the build script's business,
162 - /// because it is what generates the narrowing CSS, so only the width is
163 - /// restated here; a renderer with no stylesheet reads it off the same order.
160 + /// Seven columns, four of them sortable. This is the description that survives
161 + /// the flip; `build.rs`'s `TASK_COLUMNS` says the same thing for the JS table
162 + /// and goes away with it (finding 1 above). The priority a column has when room
163 + /// runs out is the build script's business, because it is what generates the
164 + /// narrowing CSS, so only the width is stated here; a renderer with no
165 + /// stylesheet reads it off the same order.
164 166 const COLUMNS: [(&str, Width, Option<TaskSortColumn>); 7] = [
165 167 (
166 168 "description",
M src-tauri/src/quasi/task_list/tests.rs +4 -4
@@ -105,15 +105,15 @@
105 105 }
106 106
107 107 #[tokio::test]
108 - async fn the_table_is_the_columns_the_build_script_describes_in_that_order() {
108 + async fn the_table_is_the_columns_the_screen_describes_in_that_order() {
109 109 let state = state().await;
110 110 task(&state, "Write the thing");
111 111
112 112 let markup = screen(&state);
113 113
114 - // The same seven, in the same order, as `build.rs`'s TASK_COLUMNS. Finding
115 - // 1 in the module header: the two descriptions agree and nothing but this
116 - // checks that they do.
114 + // The seven the described table names, in the order it names them. Read off
115 + // COLUMNS, not off `build.rs`: this checks the described screen against
116 + // itself, and it keeps working after TASK_COLUMNS is deleted at the flip.
117 117 let mut at = 0;
118 118 for name in [
119 119 "description",