Repository navigation
Conversation
A poll asks on a timer, and a file's details are asked for once and kept, so a plugin whose state changes on its own (a sync finishing) showed it late, or not until F5. A manifest's "watch" is a command Folio leaves running; each line it prints has the plugin polled at once and its details asked for again. Lines that come close together are acted on once, a watch that ends is started again every 5 seconds, and it ends with Folio or its plugin, with everything it started. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
[Medium impact] The PR appears safe to merge, with a non-blocking concern about repeated commands for files the user has left. Findings
SummaryAdds a plugin
Reviews (3) · Last reviewed commit: "Let go of a details command's callers on..." · Reviewed by Greptile |
…a watch's last error line A watch printing a line every half second had each details command's answer dropped before it came, so a command slower than that showed nothing for a file until the watch went quiet, while the dropped commands kept running. A command still running when its plugin's state changes is now left to finish, its answer shown, and run once more after, as a poll is. F5 still drops the answers on their way. A watch ending on a line of standard error without a newline has it printed too, as other commands do, since it can be the only reason it stopped. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
While a watch kept printing, every answer was an early one, and its callers were kept for the command's next run while each change added another, so the list grew for as long as the watch went on. Callers are now let go once told, the next run starts without any, and whoever shows the file is told to read it again when that run had nobody waiting. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
| const Manifest *m = early ? manifest(id) : nullptr; | ||
| if (m && !m_asking.contains(key)) { | ||
| m_asking.insert(key, {}); | ||
| ask(*m, path, key); |
There was a problem hiding this comment.
Old files keep running commands
When a watch keeps printing faster than its details command finishes, these follow-ups keep running for files the user has left. Each follow-up starts with no callers, so wanted is empty and the selection check is skipped. Later watch changes mark it for another run again.
Browsing through files therefore leaves more commands running repeatedly until the watch goes quiet or F5 clears them. Preserve a way to check whether anyone still wants the file without keeping callers that already received their answer.
Closes #77.
A manifest's
watchis a command Folio starts when the plugins are read and leaves running. Each line it prints has the plugin polled at once and its details asked for again, so a sync finishing shows in the details pane when it happens, not at the next F5.The first line is acted on at once and those within half a second after it together, so a watch can print one per change. One that ends is started again every 5 seconds; it ends with Folio or its plugin, with everything it started, and F5 leaves a running one be. Unlike the other commands it isn't waited for in a pool: its lines come in as events on Folio's own thread.
This is only the interface, with tests and a section in docs/plugins.md. No bundled plugin uses it yet. As an example of one that would, a Nextcloud plugin gets its watch in cornedor#1: the commit adds a two-line
watchthat stays on the Nextcloud client's socket, so a file's row in the details pane follows a sync as it goes.🤖 Generated with Claude Code