emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] ANN: org-super-agenda


From: Adam Porter
Subject: Re: [O] ANN: org-super-agenda
Date: Fri, 28 Jul 2017 20:00:40 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Eric S Fraga <address@hidden> writes:

> Hi Adam,
>
> have now given this a try.  Looks really nice.  Some questions, if I
> may.  I would like to have the following sections:

Hi Eric,

Thanks, I appreciate your feedback.

> 1. items that have deadlines, any deadline for now and in the future,
>    whether scheduled or not.
> 2. items that have a specific TODO type whether scheduled or not.

Well, as it stands, this package is mainly a way to group together items
that the standard agenda view (i.e. the org-agenda-list function) has
gathered.  The standard agenda view uses org-agenda-get-day-entries for
that.  What I think you're wanting is already provided by, e.g. the
org-todo-list function.  So you could add that as a separate section in
a custom agenda series command.

Now if you're wanting to use the grouping ability on the global TODO
list provided by org-todo-list, that is a possibility, but it would
require my essentially copying the org-todo-list function and making it
available under a new name that does the grouping.  This is what I did
with the org-agenda-list function: I just copied it and made one change
that calls my grouping/inserting functions instead of inserting results
directly.

The problem with this approach in general is that I end up copying large
Org agenda functions (and they are large) and making minor changes to
them, and then they will get out of sync when those functions change in
Org.

So the question becomes, how many Org agenda functions do I want to copy
into my package and be responsible for fixing?

I considered an alternative approach of post-processing agenda buffers,
instead of doing the filtering and inserting myself, but considering all
the special blocks that agenda buffers can have (e.g. clockreports,
timelines, etc), I decided that down that path lies madness.  ;)

So I'm not sure how far I should go with adding these other agenda types
to this package.  It would be nice if the agenda functions in Org itself
could be modified to accept grouping functions like this (it's a minor
change, really, to call a function to do insertion instead of doing it
directly), and that's something that I'd eventually like to propose to
the maintainers.

> 3. a clock summary (equivalent to what one gets with "v c" in standard
>    view)

I confess that I have never used this feature before you mentioned it.
:)  I tried to investigate this, but I've hit somewhat of a dead end:
the org-agenda-show-log-scoped variable, which is bound by
org-agenda-list, for some reason becomes unbound in org-super-agenda,
which doesn't seem to make sense, since it is just a copy of
org-agenda-list.  And even using edebug and stepping through everything
I can find, I can't figure out why it becomes unbound.

...And, having written that, it suddenly occurred to me: I wonder if
org-agenda-show-log-scoped is defined with defvar...and I see that it is
not...and so I tried doing it...and it seems to have fixed that
problem.  I guess I don't realy know anything until I explain it to
someone else.  :)

Now I can go ahead and add that defvar to my package for now, but it
should probably be added to Org itself.  It might be considered a bug
fix, but on the other hand, if it only happens with my non-standard
package...

Anyway, I will add this to my package and upload it shortly.  Please let
me know if it fixes the clockcheck command for you.

> 4. a clock report at the end (and really the end, after all other
> items)

As far as I know, this already works.  Just press "R" in the agenda
buffer.  Please let me know if it doesn't work for you.

After thinking about this some more, I have an idea: if I go ahead and
import the agenda-building functions into my package and modify them, I
can use a minor mode to override the standard functions with advice.
That way users would only have to define the groups variable, and all
the agenda commands would pick it up automatically, from the user's
perspective.  That would prevent users from having to define new agenda
commands that call special functions; they could just use their existing
custom agenda commands.

I will look into this and push it to the repo if it works.  Please let
me know if you have any other ideas or suggestions.

Thanks,
Adam




reply via email to

[Prev in Thread] Current Thread [Next in Thread]