--- /dev/null
+Return-Path: <gmn-notmuch@m.gmane.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 3A0C9431FBF\r
+ for <notmuch@notmuchmail.org>; Fri, 12 Dec 2014 04:10:34 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.165\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.165 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_LOW=-0.7, RCVD_NUMERIC_HELO=0.865]\r
+ autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id Lc3A0H0I9Zdd for <notmuch@notmuchmail.org>;\r
+ Fri, 12 Dec 2014 04:10:30 -0800 (PST)\r
+Received: from plane.gmane.org (plane.gmane.org [80.91.229.3])\r
+ (using TLSv1 with cipher AES256-SHA (256/256 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id EECC6431FBC\r
+ for <notmuch@notmuchmail.org>; Fri, 12 Dec 2014 04:10:29 -0800 (PST)\r
+Received: from list by plane.gmane.org with local (Exim 4.69)\r
+ (envelope-from <gmn-notmuch@m.gmane.org>) id 1XzP39-0003Xp-64\r
+ for notmuch@notmuchmail.org; Fri, 12 Dec 2014 13:10:23 +0100\r
+Received: from 151.62.31.98 ([151.62.31.98])\r
+ by main.gmane.org with esmtp (Gmexim 0.1 (Debian))\r
+ id 1AlnuQ-0007hv-00\r
+ for <notmuch@notmuchmail.org>; Fri, 12 Dec 2014 13:10:23 +0100\r
+Received: from lele by 151.62.31.98 with local (Gmexim 0.1 (Debian))\r
+ id 1AlnuQ-0007hv-00\r
+ for <notmuch@notmuchmail.org>; Fri, 12 Dec 2014 13:10:23 +0100\r
+X-Injected-Via-Gmane: http://gmane.org/\r
+To: notmuch@notmuchmail.org\r
+From: Lele Gaifax <lele@metapensiero.it>\r
+Subject: Re: New "notmuch address" command\r
+Date: Fri, 12 Dec 2014 13:10:11 +0100\r
+Organization: Nautilus Entertainments\r
+Lines: 66\r
+Message-ID: <874mt19iho.fsf@nautilus.nautilus>\r
+References: <878uid9qjl.fsf@nautilus.nautilus>\r
+ <87ppbpf8yy.fsf@steelpick.2x.cz>\r
+Mime-Version: 1.0\r
+Content-Type: text/plain; charset=utf-8\r
+Content-Transfer-Encoding: 8bit\r
+X-Complaints-To: usenet@ger.gmane.org\r
+X-Gmane-NNTP-Posting-Host: 151.62.31.98\r
+User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)\r
+Cancel-Lock: sha1:xSuHjrP5BcG1yuZJbgc98KHmiCI=\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Fri, 12 Dec 2014 12:10:34 -0000\r
+\r
+Michal Sojka <sojkam1@fel.cvut.cz> writes:\r
+\r
+>> An (almost) equivalent of "notmuch-addrlookup foo" could be "notmuch\r
+>> address to:foo* OR from:foo*", but it has at least one indesiderable\r
+>> difference: it seems considering the "CC" field, but always emits the\r
+>> "TO" content (i.e., assuming I have a message I sent to "john@doe.com"\r
+>> and CCed to "foo@bar.com", "notmuch address to:foo" emits\r
+>> "john@doe.com", not "foo@bar.com") so the candidates it generates are\r
+>> way too much.\r
+>>\r
+>> I don't know it that's done on purpose (I clearly miss the use case if\r
+>> so).\r
+>\r
+> Yes, this is expected behavior. Notmuch address is basically a wrapper\r
+> around search command. The command does not interpret the query at all,\r
+> because there might be no from:/to: term. The use case was to SIMPLIFY\r
+> address completers.\r
+\r
+Ok, even if I still miss the point of searching for an address and\r
+obtaining (only, see below) something (apparently) unrelated.\r
+\r
+>> I wonder if it would be reasonable adding a "--complete" flag to the\r
+>> "address" command that selects a more specific behaviour, so that\r
+>> "notmuch address --complete foo":\r
+> ...\r
+>> b) searches the given text only in the related headers (hiding the\r
+>> difference between "incoming" and "outgoing" messages, \r
+>\r
+> This should be configurable, because --output=sender is much faster than\r
+> --output=recipients. I think that ideal address completion should offer\r
+> you the addresses you have already written to, i.e.\r
+>\r
+> notmuch address --output=recipient from:my@address to:"prefix*"\r
+>\r
+> But this may be too slow on non-SSD disks. Some users may therefore prefer\r
+>\r
+> notmuch address --output=sender to:my@address from:"prefix*"\r
+>\r
+> which would be faster, but also includes every spammer/robot/... who\r
+> sends anything to you.\r
+\r
+Yes, seems reasonable!\r
+\r
+>> and not\r
+>> considering the body at all)\r
+>\r
+> What considers body now?\r
+\r
+Well, "notmuch address foo" currently does that, and that sounds useful,\r
+to obtain a list of recipients who talked about "foo".\r
+\r
+>> c) avoids the "bug"/"feature" explained above\r
+>\r
+> Yes, if you know the substring you are looking for, implementing a\r
+> filter would be trivial.\r
+\r
+It's not just a matter of filtering, but rather *which* address is\r
+emitted: trying it out, in the case above the "foo@bar.com" is not even\r
+mentioned in the output, because it appears only as a CCed recipient.\r
+\r
+thank you,\r
+ciao, lele.\r
+-- \r
+nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri\r
+real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.\r
+lele@metapensiero.it | -- Fortunato Depero, 1929.\r
+\r
projects / notmuch-archives.git / commitdiff