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