Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 13897431FAF for ; Wed, 5 Nov 2014 04:24:11 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FiyazWQSo4D for ; Wed, 5 Nov 2014 04:24:03 -0800 (PST) Received: from max.feld.cvut.cz (max.feld.cvut.cz [147.32.192.36]) by olra.theworths.org (Postfix) with ESMTP id 92586431FAE for ; Wed, 5 Nov 2014 04:24:03 -0800 (PST) Received: from localhost (unknown [192.168.200.7]) by max.feld.cvut.cz (Postfix) with ESMTP id 449FB5CD26F; Wed, 5 Nov 2014 13:23:59 +0100 (CET) X-Virus-Scanned: IMAP STYX AMAVIS Received: from max.feld.cvut.cz ([192.168.200.1]) by localhost (styx.feld.cvut.cz [192.168.200.7]) (amavisd-new, port 10044) with ESMTP id d01Jy_ID88Tj; Wed, 5 Nov 2014 13:23:54 +0100 (CET) Received: from imap.feld.cvut.cz (imap.feld.cvut.cz [147.32.192.34]) by max.feld.cvut.cz (Postfix) with ESMTP id 196515CD26A; Wed, 5 Nov 2014 13:23:53 +0100 (CET) Received: from wsh by steelpick.2x.cz with local (Exim 4.84) (envelope-from ) id 1Xlzcu-000669-T2; Wed, 05 Nov 2014 13:23:52 +0100 From: Michal Sojka To: Mark Walters , notmuch@notmuchmail.org Subject: Re: [PATCH v2 06/10] cli: Introduce "notmuch address" command In-Reply-To: <87d291ao34.fsf@qmul.ac.uk> 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> User-Agent: Notmuch/0.18.2+178~g6e9e8bb (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Date: Wed, 05 Nov 2014 13:23:52 +0100 Message-ID: <87y4rpkf8n.fsf@steelpick.2x.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 12:24:11 -0000 On Wed, Nov 05 2014, Mark Walters wrote: > On Tue, 04 Nov 2014, Michal Sojka wrote: >> On Tue, Nov 04 2014, Mark Walters wrote: >>> On Mon, 03 Nov 2014, Michal Sojka 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=3Dfil= es >>> say. Also I can imagine calling notmuch address --limit=3D1000 ... to g= et >>> 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 the= 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:-)). Do I miss something? -Michal