ANN: org-ql agenda block support

ANN: org-ql agenda block support

[Adam Porter]

Hi friends,

FYI, I just pushed a new feature to org-ql: custom agenda blocks.  This
allows the use of org-ql queries in custom agenda commands.

https://github.com/alphapapa/org-ql#function-org-ql-block

For example, these two custom commands are equivalent:

#+BEGIN_SRC elisp
  ;; Org Agenda tags-todo version:
  (setq org-agenda-custom-commands
        '(("ces" "Custom: Agenda and Emacs SOMEDAY [#A] items"
           ((tags-todo "PRIORITY=\"A\"+Emacs/!SOMEDAY")
            (agenda)))))
            
  ;; org-ql version:
  (setq org-agenda-custom-commands
        '(("ces" "Custom: Agenda and Emacs SOMEDAY [#A] items"
           ((org-ql-block '(and (todo "SOMEDAY")
                                (tags "Emacs")
                                (priority "A")))
            (agenda)))))
#+END_SRC

However, the org-ql-block version runs in about 1/5th the time (0.7
seconds compared to 3.45 seconds on my collection of org-agenda-files).

org-ql started as a prototype for a "next-generation agenda" called
org-agenda-ng, but it evolved into its own package, which also provides
tools like org-ql-agenda and org-ql-search that provide agenda-like
views.

Please let me know if you have any feedback.

Thanks,
Adam

Re: ANN: org-ql agenda block support

[Mikhail Skorzhinskii]

Adam Porter <adam@alphapapa.net> writes:
 > However, the org-ql-block version runs in about 1/5th the time (0.7
 > seconds compared to 3.45 seconds on my collection of org-agenda-files).

For some reason I thought that on average org-ql package is working
slower then native org-agenda searches. Probably because there are more
control and interface is much more simpler and cleaner and nothing
comes free of charge. That sort of thing. :-)

I am really glad that I was mistaken. Care to drop a few thoughts on why
this is the case? This is applicable only for ql-block or other org-ql
functions are a bit faster too?

Mikhail Skorzhinskii

Re: ANN: org-ql agenda block support

[Milan Zamazal]

>>>>> "AP" == Adam Porter <adam@alphapapa.net> writes:

    AP> FYI, I just pushed a new feature to org-ql: custom agenda
    AP> blocks.  This allows the use of org-ql queries in custom agenda
    AP> commands.

[...]

    AP> Please let me know if you have any feedback.

Hi Adam,

thank you for the feature.  I looked at org-ql and org-super-agenda (for
the first time) and they look interesting.  So interesting that I've
decided to convert my agendas to it, with some improvements.  It took a
lot of effort and was sometimes tricky (although probably not more than
standard Org agendas) but the result is nice and worth it.

I've sent some feedback to the GitHub issue tracker.  On the positive
note, org-ql + org-super-agenda is superfast, agenda definitions are
much easier to read, they are also relatively easy to write (once one
finds out how) and I like the added flexibility.  Overall, I like it,
it's nice and useful, indeed something like org-agenda-ng.  Thank you
for your work!

Thanks,
Milan

Re: ANN: org-ql agenda block support

[Samuel Wales]

i have been watching these developments with interest.  i want a
faster 2-day agenda, and really like the idea of a lisp syntax for
querying, perhaps one that can combine text search with structured.

so just so it's known that there is otherwise silent interest.
limited in computer use so cannot switch but following.

-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

Re: ANN: org-ql agenda block support

[Adam Porter]

Milan Zamazal <pdm@zamazal.org> writes:

> Hi Adam,
>
> thank you for the feature.  I looked at org-ql and org-super-agenda (for
> the first time) and they look interesting.  So interesting that I've
> decided to convert my agendas to it, with some improvements.  It took a
> lot of effort and was sometimes tricky (although probably not more than
> standard Org agendas) but the result is nice and worth it.
>
> I've sent some feedback to the GitHub issue tracker.  On the positive
> note, org-ql + org-super-agenda is superfast, agenda definitions are
> much easier to read, they are also relatively easy to write (once one
> finds out how) and I like the added flexibility.  Overall, I like it,
> it's nice and useful, indeed something like org-agenda-ng.  Thank you
> for your work!

Hi Milan,

Thanks for the kind words.  I'm glad they're useful to you.  And thanks
for your feedback on the tracker; it's very helpful.

Re: ANN: org-ql agenda block support

[Adam Porter]

Samuel Wales <samologist@gmail.com> writes:

> i have been watching these developments with interest.  i want a
> faster 2-day agenda, and really like the idea of a lisp syntax for
> querying, perhaps one that can combine text search with structured.
>
> so just so it's known that there is otherwise silent interest.
> limited in computer use so cannot switch but following.

I appreciate the feedback nonetheless.

A two-day agenda could be done something like this:

    (org-ql-agenda (org-agenda-files)
      (and (or (deadline :from today :to +1)
               (scheduled :from today :to +1)
               (ts-active :from today :to +1))
           (not (done)))
      :sort (date priority todo)
      :super-groups ((:auto-planning t)))

To show deadlined entries taking org-deadline-warning-days into account,
more like the traditional Org Agenda, use (deadline auto), like:

    (org-ql-agenda (org-agenda-files)
      (and (or (deadline auto)
               (scheduled :from today :to +1)
               (ts-active :from today :to +1))
           (not (done)))
      :sort (date priority todo)
      :super-groups ((:auto-planning t)))

Grouping by date in this example is done with the org-super-agenda
:auto-planning selector, which uses the earliest planning timestamp in
an entry.  So it's not exactly like Org Agenda, but it approximates what
you're asking for, and org-ql's built-in caching may provide a speedup
for subsequent calls.

Here's an example that's similar to the Org Agenda's Log Mode:

    (org-ql-agenda
      (or (and (not (done))
               (or (habit)
                   (deadline auto)
                   (scheduled :to today)
                   (ts-active :on today)))
          (closed :on today))
      :sort (date priority todo))

Re: ANN: org-ql agenda block support

[Samuel Wales]

thanks, looks gorgeous!  i will file it for a possible future time
when i can run it, diff it with existing agenda to make sure it's the
same for me, and just switch over to it.  (i use 2d and 7d agendas and
text search view with and without inactive.)

i'll ask a couple of questions.

a while back i posted some notes on something that i was going to
implement (but wasn't able to), because somebody asked for it, hoping
that the notes would help him/her.

the idea was that we can resurrect the timeline view, for all agenda
files instead of only one, merely by a use of a text search custom
agenda view.  timestamps go where categories currently go.  sorted by
that ts.

if an entry has more than one ts (active bare, inactive bare including
on header, or planning -- other stuff requires org support), then it
will get more than one agenda line.

so this requires modifying that list that is there for the user to
modify tasks before displaying them.

can any of this stuff do that?

i keep wanting this feature: do a text search and have all matching
org-agenda-files outline entries show, with more than one agenda line
if more than one ts in entry, sorted by that ts.

so for example you search for "melatonin" (or even "." meaning all
entries, such as for an agenda restriction) and then you get to see
the most recent thing you did for melatonin or in that restriction at
the top.  and everything else you did below.  (assuming reverse sort.)

i can post more accurate and precise details if needed, but i wanted
to know if you think your work can support this.

also, does it support all the usual variables for leaders and faces and so on?

it all sounds promising.

more speed and beautiful sexps!  what more could we ask for?  :)


On 8/30/19, Adam Porter <adam@alphapapa.net> wrote:
> Samuel Wales <samologist@gmail.com> writes:
>
>> i have been watching these developments with interest.  i want a
>> faster 2-day agenda, and really like the idea of a lisp syntax for
>> querying, perhaps one that can combine text search with structured.
>>
>> so just so it's known that there is otherwise silent interest.
>> limited in computer use so cannot switch but following.
>
> I appreciate the feedback nonetheless.
>
> A two-day agenda could be done something like this:
>
>     (org-ql-agenda (org-agenda-files)
>       (and (or (deadline :from today :to +1)
>                (scheduled :from today :to +1)
>                (ts-active :from today :to +1))
>            (not (done)))
>       :sort (date priority todo)
>       :super-groups ((:auto-planning t)))
>
> To show deadlined entries taking org-deadline-warning-days into account,
> more like the traditional Org Agenda, use (deadline auto), like:
>
>     (org-ql-agenda (org-agenda-files)
>       (and (or (deadline auto)
>                (scheduled :from today :to +1)
>                (ts-active :from today :to +1))
>            (not (done)))
>       :sort (date priority todo)
>       :super-groups ((:auto-planning t)))
>
> Grouping by date in this example is done with the org-super-agenda
> :auto-planning selector, which uses the earliest planning timestamp in
> an entry.  So it's not exactly like Org Agenda, but it approximates what
> you're asking for, and org-ql's built-in caching may provide a speedup
> for subsequent calls.
>
> Here's an example that's similar to the Org Agenda's Log Mode:
>
>     (org-ql-agenda
>       (or (and (not (done))
>                (or (habit)
>                    (deadline auto)
>                    (scheduled :to today)
>                    (ts-active :on today)))
>           (closed :on today))
>       :sort (date priority todo))
>
>
>
>


-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

Re: ANN: org-ql agenda block support

[Adam Porter]

Samuel Wales <samologist@gmail.com> writes:

> the idea was that we can resurrect the timeline view, for all agenda
> files instead of only one, merely by a use of a text search custom
> agenda view.  timestamps go where categories currently go.  sorted by
> that ts.
>
> if an entry has more than one ts (active bare, inactive bare including
> on header, or planning -- other stuff requires org support), then it
> will get more than one agenda line.
>
> so this requires modifying that list that is there for the user to
> modify tasks before displaying them.
>
> can any of this stuff do that?
>
> i keep wanting this feature: do a text search and have all matching
> org-agenda-files outline entries show, with more than one agenda line
> if more than one ts in entry, sorted by that ts.
>
> so for example you search for "melatonin" (or even "." meaning all
> entries, such as for an agenda restriction) and then you get to see
> the most recent thing you did for melatonin or in that restriction at
> the top.  and everything else you did below.  (assuming reverse sort.)
>
> i can post more accurate and precise details if needed, but i wanted
> to know if you think your work can support this.

I don't recall using the timeline view much, so I'm not very familiar
with it.  From your description, it's certainly possible to do that with
a bit of code.  Basically, it would work like this:

1.  Run an org-ql query to find entries which have the type of timestamp
you're looking for, with or without any date/time bounds, and with or
without any additional query parameters.  So the query could be as
simple as, e.g. (ts) or (ts-active), or it could be something like:

    (and "melatonin" (ts :from -60))

Which would select all entries mentioning "melatonin" which have any
kind of timestamp within the last 60 days.

2.  The :action argument to org-ql would be a function which returns a
list containing the necessary heading information (e.g. heading text,
marker, etc.) and all timestamps found in the entry.  Something like:

    (lambda ()
      (list (point-marker) (org-get-heading)
            (cl-loop with limit = (org-entry-end-position)
                     while (re-search-forward org-ts-regexp-both
                                              limit t)
                     collect (match-string 0))))

3.  The results of the query would be a list of lists returned by the
:action function.  Then, you can do whatever you like with that.  It
wouldn't take much code to insert entries into a buffer with each
heading on a line and its timestamps on following lines.

...

Here's a quick prototype.  Note that the timestamps aren't propertized,
so to jump to an entry, you must use the heading; and I didn't bother to
format the timestamps like Org does; and the "date" sorting actually
sorts by the planning line at the moment, rather than other timestamps;
but things like that can easily be polished.

Note that despite my mangling it, Gnus is probably going to wrap these
lines, making the code very ugly, and I can't quickly find how to stop
that, so you might want to use e.g. lispy to reformat it.

(cl-defun org-ql-timeline (buffers-files query)
  (let ((results
         (org-ql-select buffers-files
           query :action
           (lambda ()
             (let* ((heading-string
                     (->> (org-element-headline-parser
                           (line-end-position))
                          org-ql--add-markers
                          org-ql-agenda--format-element))
                    (timestamps
                     (cl-loop with limit = (org-entry-end-position)
                              while (re-search-forward org-ts-regexp-both
                                                       limit t)
                              collect (ts-parse-org (match-string 0))))
                    (timestamp-strings
                     (->> timestamps
                          (-sort #'ts<)
                          (--map (concat "    " (ts-format it))))))
               (s-join "\n" (cons heading-string timestamp-strings))))
           :sort '(date))))
    (org-ql-agenda--agenda nil nil :strings results)))

Use it like this:

  (org-ql-timeline (org-agenda-files)
                   '(and "Emacs" (ts)))

That produces a view like this:

  WAITING [#C] org-link-match struct and functions  344d ago     :current:Emacs:
    2018-09-13 05:54:00 -0500
    2018-09-20 00:00:00 -0500
  NEXT Emacs timers and frames  348d ago                         :current:Emacs:
    2018-06-11 08:41:00 -0500
    2018-06-14 20:34:00 -0500
    2018-09-16 00:00:00 -0500
  WAITING [#B] Emacs ~-defun~ macro idea  4d ago                 :current:Emacs:
    2018-07-10 17:20:00 -0500
    2019-08-26 00:00:00 -0500

So, a timeline view isn't currently implemented, but as you can see,
it can easily be done using org-ql.  Thanks for mentioning this; I'll
probably add it in a future version.

> also, does it support all the usual variables for leaders and faces and so on?

I'm not sure exactly what you mean.  Formatting of entries is not
currently done exactly as in the Org Agenda, with customizable format
strings, etc.  It does apply faces for deadline, scheduled, overdue
deadline, etc., and as you can see in the example above, it does insert
a form of relative dates, similarly to the Agenda.  It also adds most
text properties that the Agenda does, which allows some Agenda Mode
commands to work in the Org QL Search results buffer.  Making the
formatter more customizable is something on the to-do list, maybe for
version 0.3.

> it all sounds promising.
>
> more speed and beautiful sexps!  what more could we ask for?  :)

That's the idea!  :)

Re: ANN: org-ql agenda block support

[Adam Porter]

Mikhail Skorzhinskii <mskorzhinskiy@eml.cc> writes:

> Adam Porter <adam@alphapapa.net> writes:
>  > However, the org-ql-block version runs in about 1/5th the time (0.7
>  > seconds compared to 3.45 seconds on my collection of org-agenda-files).
>
> For some reason I thought that on average org-ql package is working
> slower then native org-agenda searches. Probably because there are more
> control and interface is much more simpler and cleaner and nothing
> comes free of charge. That sort of thing. :-)

Well, it might also be because it used to be generally slower, and I
tried to be clear about that whenever I mentioned it.  :)  But I've
applied a lot of optimizations to it over the past few months, so it's
generally pretty fast now, sometimes much faster.  It's hard to make a
direct comparison in some cases, depending on the complexity of the
query.  I plan to continue optimizing it as I'm able, so hopefully it
will continue improving.

> I am really glad that I was mistaken. Care to drop a few thoughts on why
> this is the case? This is applicable only for ql-block or other org-ql
> functions are a bit faster too?

Well, it's a completely different implementation.  It has two main
features which attempt to make it fast: it uses regexp searches across
buffers as much as possible, similar to org-agenda.el but in a more
flexible way (though there's still room for improvement here, especially
with complex queries); and it caches results keyed on the query, buffer,
and narrowing (cached results are discarded when a buffer is modified),
which avoids re-running the same queries for unmodified buffers.  Oh,
and it also byte-compiles query predicates and action functions to eke
out a bit more speed.

And in general, I run benchmarks and try to improve performance when
possible; you can see some of the benchmark results in the notes.org
file in the repo (not all of which are up-to-date with current org-ql
code).

org-ql-block is just a way to make use of the results returned by org-ql
queries; other ways include org-ql-agenda, org-ql-search, and of course
you can use the raw results however you like, including calling whatever
:action function you like at matching entries, to return whatever kind
of data you need, or even perform actions directly on entries.

In other words, the querying code is separate from the display-related
code, so all org-ql-block, org-ql-agenda, org-ql-search, etc. do is
format results from org-ql queries and display them.

Upcoming features include an org-ql-sparse-tree command, like
org-sparse-tree but using org-ql queries; recursive queries; and
probably a timeline view like I recently posted about.

Please let me know if you have any feedback!

Re: ANN: org-ql agenda block support

[Samuel Wales]

On 8/30/19, Adam Porter <adam@alphapapa.net> wrote:
>> also, does it support all the usual variables for leaders and faces and so
>> on?
>
> I'm not sure exactly what you mean.  Formatting of entries is not

i was merely trying to get a sense of the degree to which it is a
drop-in replacement (which i think you have said it is not).  the
question is whether the display can be made similar enough to a highly
customized traditional agenda so that diff of the agenda buffer can
find any bugs in either traditional or ql agenda.

respecting things like org-agenda-inactive-leader will reduce the need
to munge in order to make them similar enough.  not a big deal.

adding text properties like the agenda does is great for that too as a
lot of user code likely uses them.  so that will stop actual breakage.

-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

Re: ANN: org-ql agenda block support

[Adam Porter]

Samuel Wales <samologist@gmail.com> writes:

> i was merely trying to get a sense of the degree to which it is a
> drop-in replacement (which i think you have said it is not).

Right, it doesn't do everything Org Agenda does.  Since Org Agenda does
also serve as a kind of "search view," org-ql can largely serve as a
replacement for that aspect of it, providing several advantages.  But it
doesn't implement the daily/weekly-style agenda view, so it doesn't
replace that part of it.

I'll probably refactor and rename it soon, removing "agenda" from the
name to reduce confusion.  In the future I may work on an a
daily/weekly-style view as well, which might again be called
org-ql-agenda.

> the question is whether the display can be made similar enough to a
> highly customized traditional agenda so that diff of the agenda buffer
> can find any bugs in either traditional or ql agenda.

In some cases, perhaps, but while I do want to add more features from
Org Agenda, my goal isn't necessarily to reproduce it in every aspect.

> respecting things like org-agenda-inactive-leader will reduce the need
> to munge in order to make them similar enough.  not a big deal.

That's an interesting feature.  If I do support it in the future, it
will probably come after implementing a more complex Agenda-like view
that will be quite different from Org Agenda.

> adding text properties like the agenda does is great for that too as a
> lot of user code likely uses them.  so that will stop actual breakage.

Yes, with respect to text properties, I do intend to copy what Org
Agenda does, for the most part.

Thanks for your feedback.

Re: ANN: org-ql agenda block support

[Samuel Wales]

thanks for your clarification.  i had thought that it did the
daily/weekly agenda also.  that's the one that is slow for me.


On 9/7/19, Adam Porter <adam@alphapapa.net> wrote:
> Samuel Wales <samologist@gmail.com> writes:
>
>> i was merely trying to get a sense of the degree to which it is a
>> drop-in replacement (which i think you have said it is not).
>
> Right, it doesn't do everything Org Agenda does.  Since Org Agenda does
> also serve as a kind of "search view," org-ql can largely serve as a
> replacement for that aspect of it, providing several advantages.  But it
> doesn't implement the daily/weekly-style agenda view, so it doesn't
> replace that part of it.
>
> I'll probably refactor and rename it soon, removing "agenda" from the
> name to reduce confusion.  In the future I may work on an a
> daily/weekly-style view as well, which might again be called
> org-ql-agenda.
>
>> the question is whether the display can be made similar enough to a
>> highly customized traditional agenda so that diff of the agenda buffer
>> can find any bugs in either traditional or ql agenda.
>
> In some cases, perhaps, but while I do want to add more features from
> Org Agenda, my goal isn't necessarily to reproduce it in every aspect.
>
>> respecting things like org-agenda-inactive-leader will reduce the need
>> to munge in order to make them similar enough.  not a big deal.
>
> That's an interesting feature.  If I do support it in the future, it
> will probably come after implementing a more complex Agenda-like view
> that will be quite different from Org Agenda.
>
>> adding text properties like the agenda does is great for that too as a
>> lot of user code likely uses them.  so that will stop actual breakage.
>
> Yes, with respect to text properties, I do intend to copy what Org
> Agenda does, for the most part.
>
> Thanks for your feedback.
>
>
>


-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

Re: ANN: org-ql agenda block support

[Mikhail Skorzhinskii]

Great overview, thanks a lot.

So I give it a try and completely fell in love. On my data set it is
visibly faster then org-agenda. I also wrote a lot of code around
org-agenda over the years to support my sometimes awkward needs. And now
I just threw all this ugly code away!

That was very emotional moment for me, very good job, kind sir.

Adam Porter <adam@alphapapa.net> writes:

 > Mikhail Skorzhinskii <mskorzhinskiy@eml.cc> writes:
 >
 > > Adam Porter <adam@alphapapa.net> writes:
 > >  > However, the org-ql-block version runs in about 1/5th the time (0.7
 > >  > seconds compared to 3.45 seconds on my collection of org-agenda-files).
 > >
 > > For some reason I thought that on average org-ql package is working
 > > slower then native org-agenda searches. Probably because there are more
 > > control and interface is much more simpler and cleaner and nothing
 > > comes free of charge. That sort of thing. :-)
 >
 > Well, it might also be because it used to be generally slower, and I
 > tried to be clear about that whenever I mentioned it.  :)  But I've
 > applied a lot of optimizations to it over the past few months, so it's
 > generally pretty fast now, sometimes much faster.  It's hard to make a
 > direct comparison in some cases, depending on the complexity of the
 > query.  I plan to continue optimizing it as I'm able, so hopefully it
 > will continue improving.
 >
 > > I am really glad that I was mistaken. Care to drop a few thoughts on why
 > > this is the case? This is applicable only for ql-block or other org-ql
 > > functions are a bit faster too?
 >
 > Well, it's a completely different implementation.  It has two main
 > features which attempt to make it fast: it uses regexp searches across
 > buffers as much as possible, similar to org-agenda.el but in a more
 > flexible way (though there's still room for improvement here, especially
 > with complex queries); and it caches results keyed on the query, buffer,
 > and narrowing (cached results are discarded when a buffer is modified),
 > which avoids re-running the same queries for unmodified buffers.  Oh,
 > and it also byte-compiles query predicates and action functions to eke
 > out a bit more speed.
 >
 > And in general, I run benchmarks and try to improve performance when
 > possible; you can see some of the benchmark results in the notes.org
 > file in the repo (not all of which are up-to-date with current org-ql
 > code).
 >
 > org-ql-block is just a way to make use of the results returned by org-ql
 > queries; other ways include org-ql-agenda, org-ql-search, and of course
 > you can use the raw results however you like, including calling whatever
 > :action function you like at matching entries, to return whatever kind
 > of data you need, or even perform actions directly on entries.
 >
 > In other words, the querying code is separate from the display-related
 > code, so all org-ql-block, org-ql-agenda, org-ql-search, etc. do is
 > format results from org-ql queries and display them.
 >
 > Upcoming features include an org-ql-sparse-tree command, like
 > org-sparse-tree but using org-ql queries; recursive queries; and
 > probably a timeline view like I recently posted about.
 >
 > Please let me know if you have any feedback!

Re: ANN: org-ql agenda block support

[Adam Porter]

Mikhail Skorzhinskii <mskorzhinskiy@eml.cc> writes:

> Great overview, thanks a lot.
>
> So I give it a try and completely fell in love. On my data set it is
> visibly faster then org-agenda. I also wrote a lot of code around
> org-agenda over the years to support my sometimes awkward needs. And now
> I just threw all this ugly code away!
>
> That was very emotional moment for me, very good job, kind sir.

Hi Mikhail,

Thanks for the kind words.  I'm glad to hear that you like it.  I knew
there must be someone like you out there, if only I could get the word
to you!  :)

If you're interested, here's a demo of a new feature I plan to publish
soon, a sidebar for stored view queries:

https://github.com/alphapapa/org-ql/raw/wip/refactor-org-ql-agenda/images/org-ql-view-sidebar.gif

I think it will help bring a kind of feature parity with other to-do
list-type software, ones where you can click in a sidebar and see items
matching certain criteria displayed in a pane next to it.  With org-ql's
caching and such, switching between stored views can be very fast.  And
each one is displayed in its own buffer, so you could also e.g. show one
pane with the "today" view and another with the "this week" view.

If you'd like to help test it, you can use this branch:

https://github.com/alphapapa/org-ql/tree/wip/refactor-org-ql-agenda

e.g.:

#+BEGIN_SRC elisp
(use-package org-ql
  :quelpa (org-ql :fetcher github
	    :repo "alphapapa/org-ql"
	    :branch "wip/refactor-org-ql-agenda"))
#+END_SRC