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