I wanted to define an agenda view for tasks that I need to do, which are sorted by priority, and I wanted to show only the first few of them, to avoid the burden of choice I sometimes get if I see the full list. Then I tried to use interactive filters in that view, expecting the same number of entries to be shown but only in the filtered categories, so some new items that were initially limited would be visible now. But I learned that limits are applied before filters and it doesn't work that way, and instead the agenda only shows those items that were originally shown and which also satisfy the filter.
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? 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? Let me know what you think, and if you want me to look at it further and submit some patches Best regards!
