Ignacio Casso San Román <[email protected]> writes: > ... > All of this is documented, so it's not a bug, but makes me wonder > about why the agenda behaves like this and whether it could be > improved. The only possible advantage I see to applying limits first > would be if it allowed to stop scanning agenda files and entries when > it reached that limit, but I've also learned that's not the case, > because sorting is applied before limiting. Then, ¿what's the > advantage of limiting before filtering? If it was the other way > around, I think it would be much better in terms of usability (I > assume most people would expect it to work the way I did, but maybe > I'm wrong). > > What do you think? Does it make sense to try do it the other way > around?
See https://list.orgmode.org/orgmode/CANvjMgnGkU3mCoJrkRVbHFw_z968hQgGb3bcA6aH5SG=pe9...@mail.gmail.com/ That's the original implementation that solved the specific feature request. Whether agenda could be changed - yes it can be. Not sure if it will be easy, but certainly possible, if other people are also interested. > Also, there is a specific case in which for me this is actually a bug > or documentation should be improved: when there are blocked tasks and > org-agenda-dim-blocked-tasks is set to 'invisible. In that case, > limits are applied before ignoring blocked tasks, resulting in > potentially less results than the number specified by the limit. Would > it make sense to just ignore blocked tasks while constructing the > agenda if org-agenda-dim-blocked-tasks is set to 'invisible? I think that it is conceptually not different from filters. So, the answer depends on whether the filters need to be applied before limiting. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
