Add open task search plugin - #290
Conversation
Contributed plugin that answers "@task" / "@tasks" with every unchecked checkbox in the vault, replacing the core result set for those queries only. Other queries pass through untouched. Results are one per note rather than one per task, because the sidebar keys search results by path; each note carries its full task list in `matches` for API and MCP consumers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Big improvement on #282, thanks for reworking it properly. Two fixes and it's good to merge, both in Frontmatter is scanned as body text, so a Fenced code blocks are no longer skipped. #282 skipped them and said so; now When you strip either, blank the lines instead of removing them, Minor: |
Review on gamosoft#282 caught two ways a line becomes a task nobody wrote: a `- [ ]`-shaped entry in a note's leading `---` block, which template notes carry as ordinary metadata, and a checkbox inside a fence, which gamosoft#282 skipped and documented but the rework dropped. Both regions are now blanked line-by-line rather than removed, because `line_number` counts newlines and the sidebar uses it to jump to the task. Fence scanning follows the same CommonMark rule as the preview pipeline: same character, at least as long, nothing trailing. Ordered lists count as tasks too, so `1. [ ]` and `1) [ ]` are open tasks alongside the three bullets. `- []` still is not — GFM needs the space inside the box to render a checkbox at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The gaps in the task pattern were `\s`, which matches a newline too, so an unfilled `- [ ]` ran past the end of its own line and claimed the next one as its text. A note listing an empty checkbox above two real tasks returned two results instead of three: the first carried `- [ ] milk` as its text and pointed at the empty line, sending the sidebar to the wrong line and swallowing the task that lived below it. Every gap is now `[ \t]`, so a match stops at its line. A bare `- [ ]` matches nothing, which is right — there is no task text to list. Also note in Caveats that `@tasks` reads every note in the vault: a task list has no index behind it the way core's full-text search does, so the query costs about one cold full-text search and grows with the vault. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Thank you very much, merging already! 🙏 |
2 participants
Contributed plugin that answers "@task" / "@tasks" with every unchecked checkbox in the vault, replacing the core result set for those queries only. Other queries pass through untouched.
Results are one per note rather than one per task, because the sidebar keys search results by path; each note carries its full task list in
matchesfor API and MCP consumers.