On Wed, 05 Nov 2014, Michal Sojka <sojkam1@fel.cvut.cz> wrote: > On Wed, Nov 05 2014, Mark Walters wrote: >> On Tue, 04 Nov 2014, Michal Sojka <sojkam1@fel.cvut.cz> wrote: >>> On Tue, Nov 04 2014, Mark Walters wrote: >>>> On Mon, 03 Nov 2014, Michal Sojka <sojkam1@fel.cvut.cz> wrote: >>>>> This moves address-related functionality from search command to the >>>>> new address command. The implementation shares almost all code and >>>>> some command line options. >>>>> >>>>> Options --offset and --limit were intentionally not included in the >>>>> address command, because they refer to messages numbers, which users >>>>> do not see in the output. This could confuse users because, for >>>>> example, they could see more addresses in the output that what was >>>>> specified with --limit. This functionality can be correctly >>>>> reimplemented for addresses later. >>>> >>>> I am not sure about this: we already have this anomaly for output=files >>>> say. Also I can imagine calling notmuch address --limit=1000 ... to get >>>> a bunch of recent addresses quickly and I really am wanting to look at >>>> 1000 messages, not collect 1000 addresses. >>> >>> I think that one of the reasons for having the new "address" command is >>> to have cleaner user interface. And including "anomalies" doesn't sound >>> like a way to achieve this. I think that now you can use "date:" query >>> to limit the search. >>> >>> I volunteer to implement "address --limit" properly after 0.19. This >>> should be easy. >> >> I think this depends on how you view limit: is it to limit the output >> (roughly to run "head" on the output), or is to bound the amount of work >> notmuch has to do (eg to make sure you don't get a long delay). Your >> suggestion is definitely the former, whereas I am more worried about the >> latter: limit in your definition could take an essentially unbounded >> amount of time. > > Why? If I understand you correctly, you think of limit in terms of > messages. There is 1:N mapping between messages and addresses, where > N >= 1. If I limit the number of printed addresses, I limit the number > of messages as well. Only if N is zero (which probably can be the case > with Bcc and --output=recipients) then it can result in unbounded work > (provided you have infinite number of Bcc only messages in your > database :-)). Hi I was assuming the limit in your scheme would come after the deduplication: so notmuch would have to find "limit" distinct addresses. If the limit is applied before the deduping then I agree work is bounded (in any sane case). If limit is applied before the deduping then that seems fine. Best wishes Mark > > Do I miss something? > > -Michal