Re: [O] Is there a way to get all agenda TODOs programmatically?

[Adam Porter]

Nicolas Goaziou <address@hidden> writes:

>> I have some more code you might find useful.  I had an idea to take a
>> different approach with my org-agenda-ng code (not using org-element to
>> parse the whole buffer first), and it seems to be working well so far.
>
> Clearly, `org-element-parse-buffer' is not adequate for the task. When
> buildings the agenda view, you're most probably interested in very
> specific parts of the document, whereas Element tries to be as thorough
> as possible.

Right, so now I'm using outline-next-heading to go directly to headings.

> I suggest even to not use any org-element-* function there.

That may be the best option, however at the moment I'm using just
org-element-headline-parser, which seems to work well.  It avoids a lot
of manual gathering of data in later functions, because they can just
use the plist it creates, and it seems fast with a hacky search bound
that prevents it from going too far past the headline.

>> The code is here:
>>
>> https://github.com/alphapapa/org-agenda-ng/tree/non-element-parsing
>>
>> The code doesn't generate an identical result to the org-agenda code
>> (not yet, anyway), but it's very similar.  It lacks the agenda prefix
>> feature and full application of agenda faces (it does do a few faces
>> already).  Most, if not all, text properties are applied.  And of
>> course, more work could be done to make it look more like an official
>> agenda buffer.
>
> I don't want to sound offending, but your 400 locs library cannot
> possibly be "very similar" to 10k locs org-agenda.el. Also, after
> a cursory look, it is not clear how you solve the multi-days issue.
> I.e., AFAIU, you still run multiple checks on the same entry.

What I meant is, for my own very basic, one-day agenda view, it produces
a similar-looking result--superficially, at least.  Of course it does
not support more than probably 5% of the features and settings
org-agenda.el does, as it's barely more than a proof-of-concept.  But
maybe it would be helpful to Marcin for his idea.

> Nevertheless, I think your approach is right. I think that, at some
> point, we'll need to rewrite "org-agenda.el" from scratch, like we did
> for "org-export.el" a few years back, so it becomes manageable again. In
> the process, we definitely need to find a better replacement for
> `org-agenda-skip', as done in your library.
>
> So, in a nutshell, I think you're doing a step in the right direction.
> I hope Org can ultimately benefit from a better "org-agenda.el".

Me too.  I'm just exploring some ideas, not proposing this as a
replacement.  org-agenda.el has had hundreds, if not thousands, of hours
put into it, and a full replacement would take as long to make.