8 Commits

Include renames

Author	SHA1	Message	Date
bvandeusen	b2435d97b6	android: the editor draws the checklist instead of the markup for one ... 2992. A checklist item is a real Checkbox with its text beside it, so a box can be ticked while looking at the note — which is what M304 left undone. It changed where a checklist is STORED and never changed what the editor draws. The body is split into blocks and joined back on every edit, so the note underneath is the same markdown string it was this morning. Nothing below the editor can tell this exists: no migration, no protocol change, no new shape on the wire. A run of prose lines is ONE block, not one per line. Typing a paragraph has to feel like typing a paragraph, and a separate field under every sentence would break the caret mid-sentence. Only a checklist item earns a block, because only a checklist item needs a widget. Two things that look like detail and are not: * A block carries its own TextFieldValue, and an ID that survives insertion. Compose keys fields by position unless told otherwise, so adding an item would otherwise move every caret below it up a row. Content cannot be that key — two empty items are identical and neither is the other. * Focus is hoisted to the screen rather than kept inside BlockBody, because the toolbar's checklist button also asks for one. Two owners of one cursor is one too many. Return on an item makes the next item and puts the caret in it; on an EMPTY item the block becomes prose, which is how a list ends and how you get a paragraph after one — the same rule the plain text field used, now with somewhere to land. It appends rather than splitting at the caret: splitting an item in two is a rarity, and the caret is at the end for every ordinary use of that key. The core gains `render_item` and `DerivedItem.line`; `item_lines` and `checklist_lines` are gone, subsumed. Every renderer that walks a body line by line needs the text, the state and the position TOGETHER — asking for them separately is how two calls come to disagree about a body that changed between them. The card now reads its items from the body for the same reason, instead of from note.items, which is the same list by a longer route and one save behind. WANTS A DEVICE PASS, and the focus behaviours are what to look at: return making a row and landing in it, return twice at the end of a list getting you a paragraph, and rotation restoring the right field. CI can only prove this compiles.	2026-08-24 10:14:53 -04:00
bvandeusen	68b2a5dc8d	android: a checklist is lines of the note here too ... M304 step 6, and the surface with the least room to hide: Android has no markdown renderer at all, so the card was about to show every list twice — once as literal `- [ ] milk` in the body preview, and again as the glyph rows underneath. Same bug the web had, one commit later. The card now renders the body LINE BY LINE and draws a checkbox where one belongs, which is what puts a list between two paragraphs instead of always after them. The glyphs became tappable while they were being rewritten: ticking something off from the board without opening the note is the common gesture, and the web just gained it. The tap target is the glyph, not the row — tapping the TEXT still opens the note, the way tapping anywhere else on a card does. Kotlin gets no parser. Three implementations of the grammar is the price already paid; a fourth in Compose would be a fourth place for a checklist to change shape when it syncs. So the core exposes three pure functions instead — `checklist_lines`, `checklist_continuation`, `checklist_toggle_at` — and Kotlin does the caret arithmetic around them. Those are FREE functions, not methods, and that is the interesting constraint. The editor's body field is LOCAL state on an idle-debounced autosave, so anything that edits a checklist there has to rewrite the text the field is holding, not a row the store would hand back a moment later. Going through the store would overwrite whatever was being typed. The BOARD has no such problem — nothing there is holding a half-typed body — so the card's toggle goes through the store as usual. `toggle_at` addresses an item by LINE and COLUMN rather than a text offset, because the two sides do not count the same way: Compose measures in UTF-16 units and Rust in bytes, so the same number means different places in a note with an emoji in it. A line number is identical in every encoding, and so is a column inside the marker, which is ASCII at the start of its line. In the editor: the toolbar button inserts `- [ ] ` at the caret — the only toolbar action needing no saved note, so it works on an empty compose box the moment it opens — and Enter continues the list, or ends it on an empty item. Continuation is recognised by SHAPE inside onValueChange (exactly one more character, and it is a newline) rather than by a key event, so a paste or an autocorrect falls through untouched. EditorChecklist.kt and the four item actions are gone (rule 22). Adding, renaming, ticking or deleting an item is editing text now, and the editor already does that — through SaveText, with the same autosave and the same revision window as any other edit. KNOWN GAP, not an oversight: tapping a checkbox inside the EDITOR does nothing yet. Material3's TextField does not expose onTextLayout, so mapping a tap to a character offset means either moving the body to BasicTextField or intercepting pointer events ahead of the field — both real changes to the surface this operator uses most, and neither verifiable without a device. `checklist_toggle_at` lands here, tested, so that task is pure UI. Ticking from the board works today.	2026-08-24 08:16:57 -04:00
bvandeusen	32dafca148	core: what rustfmt actually wanted ... Three from the checker's own diff. Two are the rule I had guessed at: when a call overflows and its last argument is a closure, rustfmt keeps the earlier arguments on the line and expands the closure into a block, rather than putting every argument on its own line. The third is a stray double blank line before the test module.	2026-08-24 00:49:05 -04:00
bvandeusen	668f7faf03	core: the body is the checklist, and checklist_items is gone ... M304 steps 2 and the client half of 4, together — they cannot be separated. A commit where the store writes items into the body while push.rs still reads them from a table is one that silently pushes the wrong list, and dev publishes to the dev channel on every green build. Store: * load_items becomes items_of(body) — a parse, not a query. An item's id is its ORDINAL, which is all it ever amounted to: push.rs sent text and checked and never an id, and both sides replaced the whole list on every sync. * add_item / update_item / delete_item route through update_note, so they get revision snapshotting, #tag re-derivation and the dirty/updated_at bookkeeping without any of it being written a second time. * create_note folds its items: input into the body, and syncs tags from the FOLDED body — an item can carry a #tag too. * display_title no longer takes items, because items ARE body lines now. It strips the task marker instead: a list-only note is still named by its first item, and calling that note "- [ ] milk" would show someone the storage. Wire: items leave it. A second copy of data already in the body field of the same message is how the two come to disagree. CLIENT_PROTOCOL_VERSION and MIN_SERVER_PROTOCOL_VERSION go to 3, which is what makes this safe to land before the server: a v3 client refuses a v2 server outright rather than pushing a body whose list the old _apply_note_items would then delete. Schema v8 folds every existing row into its note's body before dropping the table. Written in Rust, not SQL: the fold has to produce exactly what derive::append_item produces, and group_concat only gained a guaranteed ORDER BY in SQLite 3.44 — a checklist that quietly reordered itself during a migration would be a poor way to learn that. updated_at and dirty are deliberately left alone, because the server's migration folds the same rows the same way and both sides land on identical bodies; marking every note dirty would push a body the server already has, from every device at once. NOT deployable yet. The server still speaks v2 and still has note_items, so a client built from this will refuse to sync until the server half lands.	2026-08-24 00:41:23 -04:00
bvandeusen	d0e3e48943	core: rustfmt splits on fn_call_width, not max_width ... Three assertions I had collapsed to one line because they fit inside max_width=100. rustfmt's fn_call_width is 60 and applies to the ARGUMENT list, so a call can sit well under the line limit and still be split vertically. Clippy and the tests were already green; this is the formatter only.	2026-08-24 00:28:08 -04:00
bvandeusen	1045db318b	core: derive checklist items from the body, the way tags already are ... First step of M304. Additive on its own — nothing calls this yet — so it can be read and tested before anything depends on it. A checklist is currently a TABLE, and a table can only ever render after the body, because a row has no idea where in the note it belongs. That is why "inline with the note" is not a styling problem: prose, three checkboxes, then more prose is not expressible at all today. derive.rs already owns "structure derived from body text" for #tags and says so in its module doc. Task lines join it rather than opening a second home for the same idea. The difference between the two is worth stating and now is: tags MATERIALISE into label rows because the board queries by label; items materialise into nothing, because nothing queries them. Their only readers are the card, the editor, and display_title. The grammar is fixed here because three languages will implement it — derive.rs, notes/checklist.py, notes/markdown.ts — and any difference between two of them is a checklist that changes shape when it syncs. `*` is accepted since markdown.ts already takes it for a plain bullet, and a rule that allowed `* item` but not `* [ ] item` would be one nobody could guess. `- [ ]` with nothing after it parses as an empty item: that is what pressing Enter on a list leaves behind, and refusing it would make a half-typed list stop being a list. `- [X]` parses and normalises to lowercase on the first rewrite, so round trips are stable. append_item spaces its output exactly as import_export.py:_note_markdown does. That is not cosmetic — the server migration will fold existing rows into bodies with the same layout, so an export taken before it and one taken after have to agree byte for byte. A stale index is inert rather than fatal: the index comes from a UI that may be a moment behind the store, and a late tap should do nothing rather than panic.	2026-08-24 00:20:32 -04:00
bvandeusen	bc22f8e249	Remove [[wiki-links]], backlinks and the graph ... Operator, 2026-08-22 (note 2897): ThoughtSync is an intermediary surface. You write here because it's easy — a notebook in your pocket — and later you recall the thing and go finish it somewhere else. Recall is the product; organization is secondary. A linking system is organization, and it isn't what this is for. So: `[[wiki-links]]`, backlinks, the `[[` autocomplete, the note_links table, `/api/notes/link-search`, `/api/notes/<id>/backlinks`, the whole graph blueprint and GraphView. Rust core loses `extract_links`, `backlinks`, `link_search` and `create_titled`; the desktop loses the three Tauri commands that exposed them. This subsumes 982d24c rather than reverting it. That commit bound links to a note id so a rename would stop rewriting other notes' bodies — real infra, but infra for a feature that is now gone, and nothing it added survives. Alembic 0023 stays in the chain anyway: it shipped in an image and may already be applied, and deleting an applied revision strands a database's version pointer. 0024 drops the table and takes the column with it. The history stays honest about the fact that it existed for a day. Two things deliberately kept, because they were serving recall and only incidentally serving links: - `/api/notes/titles` and the titles store. The command palette lists them so you can jump to a note by name. `resolve()` — the name→note lookup that only linking needed — is gone. - `display_title`. Every note still has a name for search results and export filenames. What that name is FOR changed; that it exists did not. `notes/links.py` is now `notes/tags.py`, holding the #tag→label reconciliation it always also owned. A file called links.py with no links in it would have been exactly the drift this removal is meant to end. Also swept out on the way: `_escape_like`, whose only caller was link-search, and the `graph` icon. Nothing lost that a person typed — note_links was always derived, and the `[[text]]` is still sitting in every body it was written in.	2026-08-22 12:00:57 -04:00
bvandeusenandClaude Opus 5	0a7480cf9b	core: extract the store and sync engine into a shared crate (M12 step 1) ... Android becomes a native Kotlin client over this same code (Scribe note 2730), so the local store and sync engine stop being modules of the desktop app and become `thoughtsync-core`, a crate with no UI framework in it at all. This is a move, not a rewrite, and the measurement is why: every file in local/ and sync/ already carried ZERO Tauri references — 4,980 of 6,372 lines. The coupling was 473 lines of command shim, which stays behind in the desktop crate as src/commands/. Kept as git renames so history follows the files. The desktop imports them under their old names (`use thoughtsync_core::{local, sync}`) so every call site reads exactly as before. What moved is where they live, not what they are. Two things a workspace changes that are easy to miss, both caught before pushing: [profile.release] now lives at the workspace ROOT. Cargo silently ignores profiles declared by a non-root member — leaving it in the desktop crate would have dropped lto/strip/opt-level from every release build with only a warning. And a workspace shares ONE target dir, so the bundles moved from desktop/src-tauri/target to target/. Thirteen references across publish-release, debundle-graphics, verify.sh, package-prebuilt and the workflow now point there. Pinning target-dir back would have been the smaller diff, but the Android lane also produces Rust artifacts and they do not belong under desktop/. Also retires the Tauri Android lane in the same push rather than leaving a path that is being replaced: gen/android, android.yml and docs/android-dev.md are gone, the mobile_entry_point attribute with them, and the lib drops to rlib — staticlib/cdylib existed for Tauri mobile, and the .so Android loads will be built from the core crate instead. Rule 22, no parallel path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 23:12:26 -04:00