And how would you name this overdue + incoming set?
Better default queries seem like a good idea!
Or, since Logseq can be used in so many different ways, maybe even reasonably small number of different presets to choose from?
Mine for example look like this at the moment, though I’m still a new user experimenting a lot (and trying to find the time to learn a bit of Clojure/Datalog … 
):
:default-queries
{:journals
[{:title "🧰 Now"
:query [:find (pull ?b [*])
:where
(task ?b #{"NOW" "DOING"})]
:collapsed? false}
{:title "📅 Queued up"
:query [:find (pull ?h [*])
:where
[?h :block/marker ?marker]
[(contains? #{"LATER" "TODO"} ?marker)]
[?h :block/ref-pages ?p]
[?p :block/journal? true]
[?p :block/journal-day ?d]]
:collapsed? false}
{:title "⏳ Waiting"
:query [:find (pull ?b [*])
:where
(task ?b #{"WAITING"})]
:collapsed? true}]}
I use a mixture of tasks in the journal an in project notes.
I want everything I set to NOW to show up. (So far I (un)trigger that state very deliberately.)
I want to all LATER tasks with (start:: and due:: or date::) dates with no “cut-off date” in the past and a reasonable one in the future (2 weeks?—I don’t need to see task set to start in a year or two (and, yes, I have those) … 
); right now the middle query without any “date stuff” seems the closest approximation I could find.
BTW, I’m not sure why both start::/due:: and SCHEDULED:/DEADLINE: variants exist, but a query that would catch both might make experimenting with both easier/“safer”. @memeplex Yours seems to solve that—I have to take a closer look tomorrow.
Personally I find a dedicated WAITING list useful, too.
1 Like
“To Do” would be one possibility. Of course a separate query for “Past Due” would make sense as well.
I use a mixture of tasks in the journal an in project notes.
Me too.
I want everything I set to NOW to show up.
So far this seems to be the most popular alternative.
Your “Queued up” query confuses me since there is no constraint over ?d. I believe the intention is to set constraints over referenced journal page dates, but the constraints are missing AFAICS.
I wasn’t aware of any special treatment Logseq may give to start:: and due:: properties, is that the case?
“To Do” would be one possibility
This would be misleading since there already is the TODO category which has a different meaning.
Separated lists would solve the naming issue at the expense of complexity (both in configuration code and in number of different journal sections).
I like your idea of removing the ?start limit but IMHO we need a better name for that section first.
I agree that a restraint would/should make sense. But I just started digging into this ans so far no constraint seems to bring me closer to what I wan to see. Don’t ask me why—I still don’t understand an lot of this. I’m basically just wildly kicking at queries until stuff comes out. 
Probably no special treatment, you’re right. Seems to catch tasks that have a date basically anywhere in them.
I modified the one query like this—hopefully it makes a bit more sense now:
{:title "📅 Queued up"
:query [:find (pull ?h [*])
:in $ ?start ?next
:where
[?h :block/marker ?marker]
[(contains? #{"LATER" "TODO"} ?marker)]
(or-join [?h ?d]
(and
[?h :block/ref-pages ?p]
[?p :block/journal? true]
[?p :block/journal-day ?d])
[?h :block/scheduled ?d]
[?h :block/deadline ?d])
(or
[(> ?d ?start)]
[(< ?d ?next)])]
:inputs [:730d-before :21d-after]
:collapsed? false}
This seems to be almost perfect.
The only thing I still have to learn is how to include (all) open journal tasks—but only from the past.
2 Likes
I was thinking why not to make the current “SCHEDULE AND DEADLINE” section just a configurable query like the others:
- It will be visually more consistent (see Messy conventions at the bottom of journal pages · Issue #6627 · logseq/logseq · GitHub).
- It can be made coherent (or even suppressed) with workflows where other default queries don’t play that well with “SCHEDULE AND DEADLINE”, perhaps because scheduled tasks already belong to another custom section.
1 Like
Based on different ideas above, this is how my default queries ended up being:
{:journals
[{:title "Ongoing"
:query [:find (pull ?h [*])
:where
[?h :block/marker ?m]
[(contains? #{"NOW" "DOING"} ?m)]]
:collapsed? false}
{:title "Incoming and overdue"
:query [:find (pull ?h [*])
:in $ ?next
:where
[?h :block/marker ?m]
[(contains? #{"LATER" "TODO"} ?m)]
(or-join [?h ?d]
(and
(or [?h :block/page ?p] [?h :block/ref-pages ?p])
[?p :block/journal? true]
[?p :block/journal-day ?d])
[?h :block/scheduled ?d]
[?h :block/deadline ?d])
[(< ?d ?next)]]
:inputs [:7d-after]
:collapsed? false}]}
- Ongoing: anything marked NOW or DOING.
- Incoming and overdue: every TODO/LATER task that is related to some date d and either should have already been started (today >= d) or is in the near horizon (d < one week from today). Here “related to some date d” means one of:
- The block belongs to journal page d
- The block references journal page d
- The block is scheduled for d
- The block has a deadline in d
I also set:
:feature/disable-scheduled-and-deadline-query? true
since it would be redundant and I believe this is better handled with custom queries.
5 Likes
Thank you for these recommendations. They are very helpful as I didn’t like the default queries as well. One more question: Is it possible to sort your Incoming and overdue query by matched date. It should be feasible using :result-transform, but how would I use ?d in that context?
You wouldn’t use ?d at all but something like (from the default config):
;; Pre-defined :result-transform function to use in Query
:query/result-transforms
{:sort-by-priority
(fn [result] (sort-by (fn [h] (get h :block/priority "Z")) result))}
You can see what attributes are available here:
Take into account that transforming results will remove grouping and breadcrumb information:
1 Like
Thanks for the useful discussion, I agree the default queries and hardcoded scheduled/deadline query have many holes that make them very unintuitive to work with.
I started with your improved versions @memeplex and made one small modification. Personally if I create a task in the journal, that doesn’t imply the task has an association with the journal date it was defined on beyond the fact that’s when I entered it. So I don’t want it to be resurfaced based on a date unless I’ve made that date association explicitly via scheduled, deadline or referencing a date. So my version ends up as follows.
{:journals
[{:title "🔨 NOW"
:query [:find (pull ?h [*])
:where
[?h :block/marker ?m]
[(contains? #{"NOW" "DOING"} ?m)]]
:collapsed? false}
{:title "📅 NEXT"
:query [:find (pull ?h [*])
:in $ ?next
:where
[?h :block/marker ?m]
[(contains? #{"LATER" "TODO"} ?m)]
(or-join [?h ?d]
(and
[?h :block/ref-pages ?p]
[?p :block/journal? true]
[?p :block/journal-day ?d])
[?h :block/scheduled ?d]
[?h :block/deadline ?d])
[(< ?d ?next)]]
:inputs [:7d-after]
:collapsed? false}]}
Can anyone point me towards documentation describing the intended behavior of the default queries? (I’m not trying to customize anything, just want to understand how the default setup is intended to work — the concepts “Now” and “Next” are not intuitive to me). Thanks! 
It’s a good question. The default queries are:
NOW - Show me only tasks that are “NOW” or “DOING” that were created on a journal page with a date in the last two weeks.
NEXT - Show me only tasks that are “NOW” or “LATER” or “TODO” that were created on a journal page with a date in the next week.
Built in Scheduled & Deadline - Show me tasks which have a “scheduled” or “deadline” date of today.
I imagine this setup would only work for someone who is putting their tasks on specific journal pages based on when they want to get to them. I’m a bit curious about the idea of adding tasks to future journal pages though.
It makes no sense at all for me because I put new tasks on today’s journal page and then never move them, using scheduled and deadline to handle any date constraints.
1 Like
Thanks for engaging with my question, but I don’t believe your definition of NEXT is correct.
Does this workflow really depend on writing in future dated journal pages? That seems counter to everything about Logseq’s workflow, which emphasizes that you should put everything in TODAY’s journal page, but I could be wrong, and would be happy to stand corrected! 
Yes I never got the NEXT query either. It is so weird lol.
Yeah it is really odd, but that’s how it works. You can see from the query and you can also test it yourself by creating a task on a future journal date.
1 Like
thanks for this one.
I believe I would prefer to see the ones for today separately.
What should I change to this one to exclude today and how to create a separate query for today?
Hi,
How can I modify this query to exclude deadline or schedule is not today:
{:title "📅 WITHIN NEXT 3 DAYS"
:query [:find (pull ?h [*])
:in $ ?next
:where
[?h :block/marker ?m]
[(contains? #{"LATER" "TODO"} ?m)]
(or-join [?h ?d]
(and
[?h :block/ref-pages ?p]
[?p :block/journal? true]
[?p :block/journal-day ?d])
[?h :block/scheduled ?d]
[?h :block/deadline ?d])
[(< ?d ?next)]]
:inputs [:3d-after]
:table-view? false
:collapsed? true}
From the other thread.
1 Like