Nicolas Goaziou <m...@nicolasgoaziou.fr> 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.
