Tisty 1.4.0
Things go where you put them, and opening Tisty stops waiting on the log.
A folder can be dragged. Drop it above another, below it, or inside it, and it
takes everything under it along — the way a folder has always moved everywhere
else, and the way it never moved here. Documents move the same way: between each
other inside a folder, or out of one and into another, dropped where you meant
rather than filed at the end. What you arrange is what you see the next time you
open the window, on this machine and on the others.
A diagram can carry a name. The window could always put a title over a mermaid
or a math block; an assistant writing through MCP could not, and the title it
tried to send was refused. Now it is the same fence in both hands, and the
instructions say so.
The guide grew the two pages it was missing. One shows what a page is by being
one, with a photograph that travels inside the document rather than pointing at
a folder on your disk. The other is about keeping code: Rust, JSON, SQL, a
command you will not remember, a diff, and a flow drawn as a diagram — each
block with its file's name in the header, and the colours going with it to the
PDF.
Coming back from a page puts you where you were. Scroll far enough down a long
document, open a page, come back, and the sheet no longer starts over at the top.
Uninstalling takes the program and leaves the person. The uninstaller closes what
is still running first — the window, and the tisty.exe mcp an assistant keeps
alive for as long as its client lives, which is why it used to say Tisty was open
after you thought it was gone — then sweeps its settings, its cache and its entry
on the PATH. Your documents, tasks and attachments stay where they are: wanting
the program gone is not wanting the work gone. On macOS and Linux, where there is
no uninstaller to hook, tisty leave does the same thing.
Opening after something else wrote is no longer a full read. The log only ever
grows, so when the only thing that changed is that it got longer, Tisty reads the
new part instead of reading all of it again. On a store of 200,000 events, opening
the window after an assistant filed one task went from 1.8 seconds to the same
quarter-second it costs when nothing happened at all. A tail is only taken when it
is genuinely a tail: one file, grown, cut on a line, holding nothing that belongs
before what was already read. Anything else — a segment closing, a file that
shrank, a copy some sync tool left beside the real one — is read the long way,
because being fast about the wrong bytes is worse than being slow.
A document that changes now asks to be carried. Writing, moving, importing,
archiving, locking or dropping one used to wait for the next sweep, up to fifteen
minutes, before it left for your other machine; only tasks asked. Reordering
inside a folder no longer costs what rebuilding the whole index costs, and a
sync that only pushes no longer reads the store twice.
What's Changed
- feat: a folder goes where you drop it, and a diagram may carry a name by @rgdevment in #21
Full Changelog: v1.3.0...v1.4.0