I propose to change the default journal queries that come in config.edn because of the following reasons:
The assumed workflow is not clear, see for example https://www.reddit.com/r/logseq/comments/u2ol49/now_tasks_on_journal_page/. I believe the intended workflow may be based on bullet journaling since it kind of assumes that every task is logged into the journal, but it’s still too obscure for the newcomer that’s unable to figure out where all this is coming from, let alone change it.
It’s not safe: after a couple of weeks ongoing (now, doing) tasks are suddenly removed from the list. So you can’t rely on this list to track your ongoing tasks and if there is an implied habit like “every week move your ongoing tasks to Sunday’s journal” then again this assumption is not clear.
It’s not safe 2: if you happen to log a task everywhere outside your journal it won’t be listed even if it’s in an ongoing state.
The implementation shows some inconsistencies: NOW query includes ongoing (now, doing) states and NEXT queries includes todo (later, todo) states but NEXT also includes now (why?) while it doesn’t include doing, which IMHO is not consistent with the inclusion of now if both workflows (later/now vs todo/doing) are to be considered equivalent.
Another quirk: ongoing tasks for today will be listed twice: once in today’s journal itself and once in the NOW section for today’s journal. This is at least confusing.
I propose to simply list all ongoing (now, doing) tasks in the NOW section.
The NEXT section should exclude now tasks and it would be nice that it also included scheduled tasks and tasks with deadlines during the next week. This way, NEXT shows an overview of what’s on the near horizon.
Also I would like to rename both sections in order to make them more workflow-agnostic (NOW is confusing for people using a todo/doing workflow):
Ongoing: for now and doing.
Incoming: for tasks in next week’s journals or scheduled or with deadlines next week.
Yes! This is one of the first things I changed when starting to use logseq. You can change them yourself in config.edn. My suggestion would be to post what you end up with here.
For instance, here’s my NEXT query:
{:title "📅 NEXT"
:query [:find (pull ?h [*])
:in $ ?start ?limit
:where
[?h :block/marker ?marker]
[(contains? #{"NOW" "LATER" "TODO"} ?marker)]
; I want to see TODOs from all pages, not just journals
; and I ignore start and limit, just show all.
; [?h :block/page ?p]
; [?p :block/journal? true]
; [?p :block/journal-day ?d]
; [(>= ?d ?start)]
; [(< ?d ?limit)]
]
:inputs [:100d :7d-after]
:collapsed? false}]}
Thanks for answering @Gary_O , yes, I’ve changed the queries myself indeed, but my intention here is to discuss new defaults, I feel that current ones are far from optimal in this area.
That’s nice – I like adding the scheduled and deadline tasks.
For me, I want to see overdue tasks as well, i.e. not just tasks for today + 7 days but older ones too, so for me I would omit the [(> ?d ?start)] part.
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 … ):
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.
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?
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.
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.
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:
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))}
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.
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!
):
); right now the middle query without any “date stuff” seems the closest approximation I could find.
