From: Mark Walters <markwalters1009@gmail.com>
To: Michal Sojka <sojkam1@fel.cvut.cz>, notmuch@notmuchmail.org
Subject: Re: [PATCH v2 06/10] cli: Introduce "notmuch address" command
In-Reply-To: <87y4rpkf8n.fsf@steelpick.2x.cz>
References: <1415058622-21162-1-git-send-email-sojkam1@fel.cvut.cz>
	<1415058622-21162-7-git-send-email-sojkam1@fel.cvut.cz>
	<87zjc72v79.fsf@qmul.ac.uk> <87y4rqliid.fsf@steelpick.2x.cz>
	<87d291ao34.fsf@qmul.ac.uk> <87y4rpkf8n.fsf@steelpick.2x.cz>
User-Agent: Notmuch/0.18.1+86~gef5e66a (http://notmuchmail.org) Emacs/23.4.1
	(x86_64-pc-linux-gnu)
Date: Wed, 05 Nov 2014 12:48:41 +0000
Message-ID: <87a945ak46.fsf@qmul.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list

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=3Dfi=
les
>>>> say. Also I can imagine calling notmuch address --limit=3D1000 ... 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=C2=A0>=3D=C2=A01. If I limit the number of printed addresses, I limit t=
he number
> of messages as well. Only if N is zero (which probably can be the case
> with Bcc and --output=3Drecipients) then it can result in unbounded work
> (provided you have infinite number of Bcc only messages in your
> database=C2=A0:-)).

Hi=20

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=20

Mark

>
> Do I miss something?
>
> -Michal