v0.9.0
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  Jean-Pierre MartineauandClaude Opus 5
|
97d19a7978 |
The popup shows a mark, not the tags around one
message_dialog draws the message it is handed and reads its spans to pick a border tone, so a markup string reaches it unparsed: the reader saw a literal [ok] and [/ok] around the checkmark, and a failed write would have been framed in the success colour, since a plain string has no spans to read a tone from. It is a styled Text now, the way every other caller writes one. Only the mark is styled. That is enough for the border to read the tone, and it leaves the path in body ink where it stays legible -- which is what the mark is for. The reason for the failure follows it muted, on its own line. The test asserts on the spans rather than on the words, because the bug was invisible to anything reading the text: the tags were *in* the string either way. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Jean-Pierre MartineauandClaude Opus 5
|
72f72b84cd |
Diagnostics is prose, so it is a written page
The block is a title, a standfirst, sections and a list under each. That is a page of writing, not a screenful of rows, and the app already knows how to draw one: the About pages' markdown renderer. So the tool states its report as before and a third projection turns it into markdown, which is exactly what the report seam was built for -- no tool touched, no report changed, one new function beside the other two faces. Being a written page buys the two things a long block most needs and that a hand-built screen had neither of. Its ## headings are landmarks, so each pins to the top row while its own section scrolls under it and ^PgUp/^PgDn step section by section; and the PicoCalc lane picks up Sect up / Sect down for the same reason a grouped list does. AboutPage already does all of it, so the page is that page with one verb added. The frame comes back with it. The bare frame was there to keep a border off every line a mouse would drag through, which mattered while copying off the screen was the only way out; saving is the way out now, so the page can be a normal screen and the save can be advertised where this app advertises verbs -- the footer hint on a desktop, the lane's one free F3 slot on the console -- instead of in the page's own body, which belongs to the report. The answer moves to a popup with it: a path is worth reading carefully, a write can fail, and the page underneath is unchanged and still there when the popup goes. Saving markdown is the same decision as drawing it. One source is what the page renders and what the file holds, and an issue tracker renders it as written, with no fence and no apology. Every value is a code span, which is correctness and not taste: a Windows path is full of backslashes that markdown reads as escapes, and an error a stranger's firmware wrote can hold an asterisk. A value already holding a backtick gets a longer fence. Rows are a list and not a table, measured rather than assumed -- a markdown table's cells are cropped with an ellipsis at 53 columns, and a bug report whose one long value is cut is missing the half that mattered. A list item wraps and hangs under its own text at any width. Two smaller things fell out. A block may carry a caption, the heading a format that has headings draws above it -- plain and JSON have no use for one and ignore it. And the host block splits in two, because a "it looks wrong" report is about the terminal and its reader should not have to pass the processor architecture on the way to it. The command line is untouched: aligned records, because that face is a stream to grep and headings are furniture on it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Jean-Pierre MartineauandClaude Opus 5
|
3c4c6ec05a |
The block is worth attaching, not only pasting
Copying off a screen is the wrong shape for anything long: you select, you scroll, you select again, and on the PicoCalc there is no clipboard to select into at all. So the page saves. s writes meshterm-diagnostics.txt into the config directory beside the log, which is the folder "send me both" already names, and meshterm diagnostics --out PATH does the same from a shell -- spelled the way config export-key --out already spells it rather than inventing a second word for writing an answer to a path. The save key forced the one concession on the bare frame. A bare frame has no footer and no F-key lane, so a page that could save and never said so would be a key nobody could find, and on the PicoCalc the lane is normally the only place an affordance is advertised at all. The page carries its own last line instead. One trailing line after a blank row costs a paste far less than a border costs it on every line, and a drag that follows the block stops above it of its own accord. Saving answers on that same line. A dialog would cover the block the reader was about to copy, and the line has to be able to say a write failed -- a read-only home, a full disk -- without inventing an error screen for it. The block stays readable either way, which is the whole reason both routes exist. The file is always the plain block, even under --json: it is there to be read by whoever opens the issue, and a document of the same facts helps them less. It is rendered at a fixed wide width so no lane crops, and with the trailing pad stripped, since Rich pads every cell to its column and that is invisible on a terminal and noise on disk. With --out the answer becomes the path, the trade config export-key already makes: a caller who asked for a file wants to be told where it is, not handed the contents they just redirected into it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Jean-Pierre MartineauandClaude Opus 5
|
6046b4ff0e |
A bug report should be one page, and a page nobody has to read first
A report that opens with "it crashed" costs three round trips before anyone knows which MeshTerm, on which OS, in which terminal, talking to which radio. The person who hit the bug is the one least able to answer: half of it is resolved at boot and shown on no screen -- whether icons draw, whether powerline separators do, which platform flavour resolved and why. Diagnostics states all of it at once, as a page under This app and as meshterm diagnostics. The page is a bare frame, and that is mechanical rather than aesthetic. The one thing it is for is getting its text out of the terminal and into an issue, and a terminal is selected by dragging: a border is characters on the same lines as the content, so every line of a line-wise selection arrives with a box-drawing glyph welded to each end. A header and a footer hint arrive as text that looks like part of the report to whoever reads the paste. So the page draws its rows and nothing besides, the frame the share screen already uses for the same kind of reason. Nothing in the block is private, and that has to be a property rather than a habit, because the whole premise is that it gets pasted in public by somebody who did not read it. No pairing PIN, no admin password, no channel secret, no private key, no position, no contact's name or key. The mesh arrives as aggregate -- a row count per table and the span the observations cover -- which is the half that explains a bug without naming anyone the reporter talks to. Two tests hold the line from opposite sides: one plants real secrets in the stores that hold them and asserts none came out, and one refuses the key *names* such a field would take, so a value the suite cannot plant is still caught by what it would arrive as. The radio is asked and never required. A report about a companion that will not connect is exactly the report most worth filing, so the failure becomes connected=no with the radio's own words in error, and every other fact still arrives. Table counts come off sqlite_master rather than a list written down here, so a table added later starts being reported the day it lands; the interesting count is always the table nobody expected to be full. Only overridden preferences are listed -- the defaults are in the source and identical for everyone. Both faces share one projection of a facts block, so the page cannot drift from what the command prints: a field added to the report reaches both without anyone remembering to. Only the layout differs, in one respect -- the scripted face crops a value too wide for its lane, which is right for a record somebody will split on whitespace and wrong for a page whose whole job is to be complete, so a long value hangs under its own block instead. A path also gains the lane constructor it never had; the machine face had always spelled one correctly and the plain face could not render one at all. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |