On 16.1.2012, at 13:18, Carsten Dominik wrote: > Hi Max, > > this is a pretty good solution if the main issue with slow agenda > is that it feels slow because you are often switching back and forth > between different agenda buffers. I like it, and I would vote for > integration into Org-mode, not as a separate package, but directly, > as an option. If Bastien agrees, maybe you could make a patch which > introduces this into the main code. > > Three comments: > > 1. I think there needs to be a command to remove all agenda buffers, to make > sure that everything is updated. Maybe this could be "C-u r" or so, which > would rebuilt the current and remove all others. This commands needs to make > sure that all markers are safely discarded - otherwise you will die the > marker death eventually. > > 2. I don't think that "-cache" is the best name choice for this, because this > is not a caching mechanism. It is a "multiple-agenda-buffers" thing. > > 3. One caveat for this is that maybe in some places, org-agenda-marker-table > is modified while the agenda buffer is not current (I am not sure, I just > think this needs to be checked). If so, one would need to pop to the > relevant agenda buffer to make the change.
Sorry, I am talking about `org-agenda-markers', and indeed, some care has to be taken here. Basically, the function org-agenda-new-marker needs to be modified to take a buffer as an argument, and then to push the new marker on the list of markers in that buffer. Also, org-agenda-save-markers-in-region needs to be modified. OK, this is a bit complicated, I am willing to help. If you make a new patch that implements the multibuffer stuff in org-agenda, I will look at the marker issues and implement them. - Carsten > > Just my 2c, of course. > > - Carsten > On 15.1.2012, at 20:47, Max Mikhanosha wrote: > >> As my agenda files slowly grew over the years, the speed of generating >> agenda had slowly deteriorated, finally hitting the point of me jdoing >> something about it. (it got to around 5-7 seconds, which kind of >> interrupts work-flow) >> >> Attached file org-agenda-cache.el is a "quick fix" solution that I >> developed for myself, its more of a request for discussion and not >> intended as contribution yet. >> >> Basic idea is: >> >> 1. Multiple-agenda buffers can exist at the same time, having separate >> tag filters and other such settings. This is accomplished by bunch of >> org-agenda-* variables being made buffer-local. >> >> 2. Custom agenda commands should bind `org-agenda-buffer-name' variable, >> so that for example C-c a generates "*Agenda*" buffer and C-c t >> generates "*Todo List*" buffer. >> >> 3. org-agenda checks if buffer with `org-agenda-buffer-name' exists >> and if it does, it will show that buffer, rather then re-generating >> it. To generate a fresh agenda, becomes C-c a r instead of C-c a >> >> 4. org-agenda-quit buries the agenda buffer instead of killing it. >> >> 5. All of the above shenanigans can be switched on and off by doing >> M-x toggle-org-agenda-caching command, its off by default so you have >> to turn it on after loading the file. >> >> I had been using this setup for last few days, and it had really been >> a blast, returning me to the times when I just started with org-mode, >> and information had appeared in milliseconds rather then seconds. >> >> <org-agenda-cache.el> >
