LogSeq Advanced Query - Basics & Tips in less then 10 min
Based on Tools on Tech's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.
Use the advanced-query begin/end wrapper when building the foundational bracketed structure, even if single query syntax exists for simpler cases.
Briefing
LogSeq advanced queries can feel like a bracket maze, but a recent shift to “single query syntax” makes them far easier—while the underlying Clojure-style logic still matters for anyone who wants reliable results. The walkthrough builds a detailed advanced query to surface a specific kind of task: to-do items that live inside journal pages, have been ignored for roughly the last 180 days, and are neither scheduled nor marked as prioritized. The practical payoff is clear: instead of hunting manually through pages, the query produces a focused backlog of “stale” tasks that deserve attention.
The query is wrapped in an advanced-query block (a begin/end structure) and uses a column-based query core. It starts by pulling all blocks via a wildcard selection (using the star selector) into a variable (commonly b for blocks). From there, it narrows aggressively: first by filtering block markers to only active to-dos—matching markers like “to do” and “doing” using a contains? check (including the important detail that the function name ends with a question mark).
Next comes exclusion logic. Tasks that already have a schedule are removed by checking whether the block has a scheduled value in the b dataset. The same pattern repeats for priority: any to-do with a priority value gets filtered out. That leaves to-dos that are active but not already handled by the two common “keep it on track” mechanisms.
Because the goal is journal-only tasks, the query then maps each to-do block to the page it sits on. It fetches the block’s page reference (block page) into a separate variable (p) and filters for pages that are journal pages. Finally, it adds a time window. It extracts the journal day value from each journal page into a day variable, then uses query variables injected via column in to represent “today” and the day from 180 days ago. The comparison logic keeps only tasks whose journal day falls between those bounds—effectively identifying to-dos that have been postponed for months.
After the core example, the transcript shifts from query logic to query craftsmanship. It recommends using LogSeq’s code block formatting with backticks and clojure to get syntax highlighting and auto-indent, but notes that it requires copy/paste to actually run. For larger queries, it suggests editing in an external tool like Visual Studio Code so formatting and auto-save make debugging faster. It also offers workflow fixes for getting back into edit mode in LogSeq, plus a deeper debugging option: opening developer tools and checking the console to see a running tally of what LogSeq is doing under the hood.
The closing advice is pragmatic: table output can be sorted by clicking column headers, and column order can be changed via an external editor. There’s also mention of future topics like formatting results, computing summaries, and using the visualizer plugin—signaling that the real skill is turning raw query output into something actionable.
Cornell Notes
The walkthrough builds a LogSeq advanced query that finds “stale” to-dos inside journal pages. It pulls all blocks, filters to active to-do markers (“to do” and “doing”), then removes any blocks that already have a scheduled value or a priority value. It restricts results to journal pages by checking the page type for each to-do block. Finally, it uses journal day data plus injected variables for “today” and “180 days ago” to keep only tasks whose journal page dates fall within that window. The practical value is a repeatable way to generate a focused backlog of neglected tasks rather than manually scanning pages.
Why do advanced LogSeq queries often look like a bracket puzzle, and what changed recently?
How does the query isolate active to-dos from all blocks?
What logic removes tasks that are already being handled?
How does it ensure results come only from journal pages?
How does the query implement the “ignored for 180 days” time window?
What debugging and editing workflow tips help when queries get complex?
Review Questions
- In the query, what two properties are checked to exclude already-managed tasks, and how are they excluded?
- How does the query connect a to-do block to its containing page, and what filter is applied to that page?
- What role do the injected variables from column in play in the 180-day time window calculation?
Key Points
- 1
Use the advanced-query begin/end wrapper when building the foundational bracketed structure, even if single query syntax exists for simpler cases.
- 2
Filter active to-dos by matching block markers with contains? for “to do” and “doing” (including the trailing question mark).
- 3
Exclude tasks that already have a schedule by checking block scheduled and removing matches with not.
- 4
Exclude tasks already marked for attention by checking block priority and removing matches with not.
- 5
Restrict results to journal pages by mapping each to-do block to its block page and filtering for journal page type.
- 6
Implement the time window by comparing journal day values against injected variables for today and 180 days ago via column in.
- 7
When debugging, prefer an external editor like Visual Studio Code for syntax clarity and faster iteration, and use developer tools console output to trace errors.