Re: [PATCH v3 10/10] cli: address: Add --filter-by option to configure address filtering
authorTomi Ollila <tomi.ollila@iki.fi>
Fri, 9 Jan 2015 14:13:00 +0000 (16:13 +0200)
committerW. Trevor King <wking@tremily.us>
Sat, 20 Aug 2016 21:47:17 +0000 (14:47 -0700)
bd/4ecca8fff3dceaa23199c018ee59280410b57b [new file with mode: 0644]

diff --git a/bd/4ecca8fff3dceaa23199c018ee59280410b57b b/bd/4ecca8fff3dceaa23199c018ee59280410b57b
new file mode 100644 (file)
index 0000000..73e8802
--- /dev/null
@@ -0,0 +1,158 @@
+Return-Path: <tomi.ollila@iki.fi>\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 836B1431FDB\r
+       for <notmuch@notmuchmail.org>; Fri,  9 Jan 2015 06:13:31 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 2.438\r
+X-Spam-Level: **\r
+X-Spam-Status: No, score=2.438 tagged_above=-999 required=5\r
+       tests=[DNS_FROM_AHBL_RHSBL=2.438] 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 sUQHJeuBrShs for <notmuch@notmuchmail.org>;\r
+       Fri,  9 Jan 2015 06:13:27 -0800 (PST)\r
+Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])\r
+       by olra.theworths.org (Postfix) with ESMTP id 7F57B431FD8\r
+       for <notmuch@notmuchmail.org>; Fri,  9 Jan 2015 06:13:27 -0800 (PST)\r
+Received: from guru.guru-group.fi (localhost [IPv6:::1])\r
+       by guru.guru-group.fi (Postfix) with ESMTP id 3B405100090;\r
+       Fri,  9 Jan 2015 16:13:00 +0200 (EET)\r
+From: Tomi Ollila <tomi.ollila@iki.fi>\r
+To: Michal Sojka <sojkam1@fel.cvut.cz>, David Bremner <david@tethera.net>,\r
+       notmuch@notmuchmail.org\r
+Subject: Re: [PATCH v3 10/10] cli: address: Add --filter-by\r
+       option  to      configure       address filtering\r
+In-Reply-To: <87egr46qcs.fsf@steelpick.2x.cz>\r
+References: <1415147159-19946-1-git-send-email-sojkam1@fel.cvut.cz>\r
+       <1415147159-19946-11-git-send-email-sojkam1@fel.cvut.cz>\r
+       <87vbkrfs66.fsf@maritornes.cs.unb.ca>\r
+       <m2d26yhfmk.fsf@guru.guru-group.fi>\r
+       <87egr46qcs.fsf@steelpick.2x.cz>\r
+User-Agent: Notmuch/0.19+14~ge04617b (http://notmuchmail.org) Emacs/24.3.1\r
+       (x86_64-unknown-linux-gnu)\r
+X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
+       $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
+       !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
+Date: Fri, 09 Jan 2015 16:13:00 +0200\r
+Message-ID: <m2h9w0ujo3.fsf@guru.guru-group.fi>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\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, 09 Jan 2015 14:13:31 -0000\r
+\r
+On Fri, Jan 09 2015, Michal Sojka <sojkam1@fel.cvut.cz> wrote:\r
+\r
+> Hi,\r
+>\r
+> sorry for longer response time :)\r
+>\r
+> On Thu, Jan 01 2015, Tomi Ollila wrote:\r
+>> On Wed, Dec 31 2014, David Bremner <david@tethera.net> wrote:\r
+>>\r
+>>> Michal Sojka <sojkam1@fel.cvut.cz> writes:\r
+>>>\r
+>>>> This option allows to configure the criterion for duplicate address\r
+>>>> filtering. Without this option, all unique combinations of name and\r
+>>>> address parts are printed. This option allows to filter the output\r
+>>>> more, for example to only contain unique address parts.\r
+>>>\r
+>>> I had the feeling there was some "controversy" about the UI here, but\r
+>>> following back the 3 versions of the series I didn't see it. Does that\r
+>>> mean we just need to sanity check the code, or are there outstanding\r
+>>> bikes to shed?\r
+>\r
+> I'd tend to rename this option to --unique as it was in some previous\r
+> version of the patch. Another thing in my mind is the implementation of\r
+> the --complete option mentioned in id:878uid9qjl.fsf@nautilus.nautilus.\r
+> This would also involve some kind of address filtering. I'll look into\r
+> this and send patches later.\r
+>\r
+>> I have intentionally been guiet on this during the review process of the\r
+>> other patches to not slow down the acceptance of the others. I have not\r
+>> got enough time to look the implemenentation or think this last patch\r
+>> further -- from the user interface point of view I recall seeing there\r
+>> both useless features (but which might be warranted by implementation\r
+>> simplicity) and missing features (but which might not be there due to \r
+>> difficulty in implementation). Also, I am not sure whether the --filter-by\r
+>> is good option (and options descriptive...)...\r
+>\r
+> I'd be interested in what are these "missing features".\r
+\r
+Last night when I tried to catch sleep I was also thinking of this...\r
+... let's see what I remember...\r
+\r
+First, Currently if we have addresses:\r
+\r
+ "Uni Que" <unique@example.org>\r
+ "Uni Que" <Unique@Example.Org>\r
+\r
+I presume these are thought as a separate addresses -- and an option to\r
+thought these as the same would be useful.\r
+\r
+but let's consider second set of addresses:\r
+\r
+ "Uni Que" <unique@example.org>\r
+ "Uni Keko" <unique@example.org>\r
+\r
+Now, if there were an option to consider these 2 as the same, that would\r
+hide user from one of the names -- It is clear that "Uni Que" is the right\r
+one but if only "Uni Keko" (sleepyhead, that is) is shown user don't have\r
+a choice to select the right one. I am not sure what the use case for\r
+"uniquing" these 2 were.\r
+\r
+Finally (for now), 3rd set of addresses\r
+\r
+ "Uni Que" <unique@example.org>\r
+ "Uni Que" <unique@foobar.invalid>\r
+\r
+Now, if there were an option to consider these 2 as same, and\r
+user is then given "Uni Que" <unique@foobar.invalid> (which clearly is\r
+the wrong one) I don't see the usefullness of this option...\r
+\r
+IMO I don't see a case having such an options there, but these are my \r
+opinions, feel free to bikes^H^H^H^H^H discuss further :D\r
+\r
+Tomi\r
+\r
+PS: The "missing features" not thought now -- the only one I can quickly\r
+remember is uniq(1) style option -- uniq consecutive addresses to one --\r
+to do this we'd first need the no-unique-at-all option... and of course\r
+I have a use case for this :D\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+>\r
+> Cheers,\r
+> -Michal\r
+> _______________________________________________\r
+> notmuch mailing list\r
+> notmuch@notmuchmail.org\r
+> http://notmuchmail.org/mailman/listinfo/notmuch\r