Rebuilding Logseq queries as saved views after a move

Most Logseq queries people rely on ask one of three things: what’s due, what’s still open, and what carries a given tag. Those rebuild cleanly as saved views in most outliners, including listlis. Queries that walk page properties, join pages to blocks, or compute over the graph with datalog don’t have an equivalent there, and you should know which of yours are which before you move.

This guide sorts your queries into those two piles, shows how to rebuild the first pile as smart lists in listlis, and says plainly what the second pile costs you. If you haven’t decided to leave yet, start with Leaving Logseq? A calm guide to your options. If you’re mid-move, the Markdown migration guide covers the import itself.

Why queries don’t travel

A Logseq query is a computation, not content. In the file-based app it sits in your Markdown as text, something like {{query (and [[project-x]] (task now later))}}, and Logseq runs it every time the page renders. Export the page and you get the text without the engine. Any other tool will show you the literal braces.

So moving a query means rebuilding the idea behind it in the new tool’s terms. That’s less work than it sounds, because most query blocks in a working graph are a handful of patterns repeated across pages.

Step 1: inventory what you actually use

Search your graph folder for {{query and #+BEGIN_QUERY. Every hit is a query block. Copy each one into a scratch page with a note on where it lived and whether you looked at it in the last month.

Expect the list to be shorter than you feared, and expect a few you’d forgotten about. A query on a page you never open is a query you don’t need to rebuild. Cross those off now.

Step 2: sort them into two piles

Logseq has two query forms. Simple queries use filters like (task now later), (between -7d today), (property type book), (page-tags project), and (priority a), combined with and, or, and not. Advanced queries are written as Datascript datalog inside a #+BEGIN_QUERY block, and can express nearly anything about the graph.

Here’s how the common shapes map onto a saved view in listlis:

Logseq query	Rebuild as a smart list?
(task now later) — open tasks	Yes: type Todo, completed hidden
(and [[project-x]] (task now later))	Yes: tag #project-x, type Todo
Tasks scheduled or due this week	Yes: due window “Next 7 days”, grouped by weekday
Overdue tasks	Yes: due window “Overdue”
Everything tagged with anything, by tag	Yes: the built-in By tag list
(or [[a]] [[b]]) across two tags	No single list; make two, or give the items a shared tag
(not [[tag]]) exclusions	No
(property type book) and other property filters	No; listlis nodes have no key-value properties
(between …) over journal dates	Partly: only if the items carry due dates
(priority a)	Only by convention, for example a #p1 tag
Advanced datalog: joins, aggregates, custom rules	No
Full-text query blocks	No saved view; use search (/) instead

The first five rows are the bulk of most graphs. The rest is where you decide whether the query was doing real work or was a habit.

Step 3: rebuild the first pile in listlis

A smart list in listlis is an ordinary node with a saved query attached. Expand it and it shows every matching node in your whole tree, each with a breadcrumb showing where it actually lives. You don’t type a query language. The editor is a set of pickers: a due window, a tag, a type, pinned or not, whether to include completed items, then how to group and sort.

To build one, press g then l to open the lists palette and choose New smart list…. The editor opens on the new list. Move with j and k, pick with Enter, and save with ⌘/Ctrl + Enter.

Three rebuilds cover most graphs:

1. Open tasks for one project. Tag project-x, type Todo, sort by due date. This replaces the most common Logseq query there is. In listlis a tag is a #project-x token in a node’s title, and a todo is any node you’ve marked with !.
2. The week ahead. You may not need to build this one. The built-in This week list (g then w) shows everything due in the next seven days, grouped by weekday, with an Overdue bucket at the top. If you want two weeks, open the lists palette and duplicate it to customize, then change the window to Next 14 days.
3. Overdue, everywhere. Due window Overdue, no grouping, sort by due date. A short list worth checking every morning.

A smart list is also a place to work, not only a report. Press c on a row to complete it. In a weekday-grouped list, J and K move an item to the next or previous day, which rewrites its due date. Press o to add an item from inside the list; it lands in your Inbox, stamped so it matches the group you created it in. Logseq’s query results are editable inline too, so this is a like-for-like trade rather than a downgrade.

One difference to plan for: Logseq tasks carry their state in a marker (TODO, DOING, LATER, NOW). listlis has one todo type and a done state, with no in-between. If you used DOING or NOW as a working set, a #doing tag and a smart list on that tag gets you back the same view.

Step 4: decide what the second pile was for

For each query left over, ask what decision it helped you make. Usually the answer falls into one of three groups.

• It answered a question you ask rarely. A reading log grouped by type:: book, a count of meetings by month. Keep the original graph folder readable, and run the query there when you need it. Leaving Logseq doesn’t mean deleting it.
• It held a set of things together. Property queries often exist because related items are scattered across journals. In an outliner the cheaper fix is often to put them in one branch: a Reading node with every book under it doesn’t need a query.
• It really did need a database. Joins across pages, aggregates, computed fields. If several of your daily queries look like this, the outline model is the wrong fit, and that’s worth knowing before you move. Tana’s supertags and fields, or staying on Logseq’s database version, will serve you better. Our Logseq OG vs database guide covers that choice.

What you gain, and what you give up

Smart lists cover a deliberately small set of filters: due window, one tag, type, pinned, completed. You give up or, not, properties, and arbitrary datalog. In exchange you get a view you can build in under a minute without syntax, that reads the same on your phone, in the web app, and to an AI assistant connected over MCP, and that you can edit from inside.

If most of your queries landed in the first pile, that’s a good trade. If most landed in the second, take it as a reason to stay.

Try it on one project

Pick the project whose task query you check most often. Import its pages, tag its open items, and build the matching smart list. If that list is the one you open the next morning, the rest of your queries will move the same way. Open listlis and try it on that one project.