d4/2c9c643c70f98688ab76515e0b3f826a9f8ad0

   1 Return-Path: <sojkam1@fel.cvut.cz>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 99A95431FDB\r
   6         for <notmuch@notmuchmail.org>; Fri,  9 Jan 2015 07:29:25 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0.138\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0.138 tagged_above=-999 required=5\r
  12         tests=[DNS_FROM_AHBL_RHSBL=2.438, RCVD_IN_DNSWL_MED=-2.3]\r
  13         autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id gLiHiy-CEDEG for <notmuch@notmuchmail.org>;\r
  17         Fri,  9 Jan 2015 07:29:23 -0800 (PST)\r
  18 Received: from max.feld.cvut.cz (max.feld.cvut.cz [147.32.192.36])\r
  19         by olra.theworths.org (Postfix) with ESMTP id 078EF431FD8\r
  20         for <notmuch@notmuchmail.org>; Fri,  9 Jan 2015 07:29:23 -0800 (PST)\r
  21 Received: from localhost (unknown [192.168.200.7])\r
  22         by max.feld.cvut.cz (Postfix) with ESMTP id 706CE4CC66C;\r
  23         Fri,  9 Jan 2015 16:29:22 +0100 (CET)\r
  24 X-Virus-Scanned: IMAP STYX AMAVIS\r
  25 Received: from max.feld.cvut.cz ([192.168.200.1])\r
  26         by localhost (styx.feld.cvut.cz [192.168.200.7]) (amavisd-new,\r
  27         port 10044)\r
  28         with ESMTP id lw0wHGCfw91H; Fri,  9 Jan 2015 16:29:18 +0100 (CET)\r
  29 Received: from imap.feld.cvut.cz (imap.feld.cvut.cz [147.32.192.34])\r
  30         by max.feld.cvut.cz (Postfix) with ESMTP id 47B1C4CC675;\r
  31         Fri,  9 Jan 2015 16:29:18 +0100 (CET)\r
  32 Received: from wsh by steelpick.2x.cz with local (Exim 4.84)\r
  33         (envelope-from <sojkam1@fel.cvut.cz>)\r
  34         id 1Y9bUz-0004dw-Sx; Fri, 09 Jan 2015 16:29:17 +0100\r
  35 From: Michal Sojka <sojkam1@fel.cvut.cz>\r
  36 To: Tomi Ollila <tomi.ollila@iki.fi>, David Bremner <david@tethera.net>,\r
  37         notmuch@notmuchmail.org\r
  38 Subject: Re: [PATCH v3 10/10] cli: address: Add --filter-by\r
  39         option  to      configure       address filtering\r
  40 In-Reply-To: <m2h9w0ujo3.fsf@guru.guru-group.fi>\r
  41 References: <1415147159-19946-1-git-send-email-sojkam1@fel.cvut.cz>\r
  42         <1415147159-19946-11-git-send-email-sojkam1@fel.cvut.cz>\r
  43         <87vbkrfs66.fsf@maritornes.cs.unb.ca>\r
  44         <m2d26yhfmk.fsf@guru.guru-group.fi>\r
  45         <87egr46qcs.fsf@steelpick.2x.cz>\r
  46         <m2h9w0ujo3.fsf@guru.guru-group.fi>\r
  47 User-Agent: Notmuch/0.18.2+178~g6e9e8bb (http://notmuchmail.org) Emacs/24.4.1\r
  48         (x86_64-pc-linux-gnu)\r
  49 Date: Fri, 09 Jan 2015 16:29:17 +0100\r
  50 Message-ID: <871tn46khe.fsf@steelpick.2x.cz>\r
  51 MIME-Version: 1.0\r
  52 Content-Type: text/plain\r
  53 X-BeenThere: notmuch@notmuchmail.org\r
  54 X-Mailman-Version: 2.1.13\r
  55 Precedence: list\r
  56 List-Id: "Use and development of the notmuch mail system."\r
  57         <notmuch.notmuchmail.org>\r
  58 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  59         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  60 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  61 List-Post: <mailto:notmuch@notmuchmail.org>\r
  62 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  63 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  64         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  65 X-List-Received-Date: Fri, 09 Jan 2015 15:29:25 -0000\r
  66 \r
  67 On Fri, Jan 09 2015, Tomi Ollila wrote:\r
  68 > On Fri, Jan 09 2015, Michal Sojka <sojkam1@fel.cvut.cz> wrote:\r
  69 >\r
  70 >> Hi,\r
  71 >>\r
  72 >> sorry for longer response time :)\r
  73 >>\r
  74 >> On Thu, Jan 01 2015, Tomi Ollila wrote:\r
  75 >>> On Wed, Dec 31 2014, David Bremner <david@tethera.net> wrote:\r
  76 >>>\r
  77 >>>> Michal Sojka <sojkam1@fel.cvut.cz> writes:\r
  78 >>>>\r
  79 >>>>> This option allows to configure the criterion for duplicate address\r
  80 >>>>> filtering. Without this option, all unique combinations of name and\r
  81 >>>>> address parts are printed. This option allows to filter the output\r
  82 >>>>> more, for example to only contain unique address parts.\r
  83 >>>>\r
  84 >>>> I had the feeling there was some "controversy" about the UI here, but\r
  85 >>>> following back the 3 versions of the series I didn't see it. Does that\r
  86 >>>> mean we just need to sanity check the code, or are there outstanding\r
  87 >>>> bikes to shed?\r
  88 >>\r
  89 >> I'd tend to rename this option to --unique as it was in some previous\r
  90 >> version of the patch. Another thing in my mind is the implementation of\r
  91 >> the --complete option mentioned in id:878uid9qjl.fsf@nautilus.nautilus.\r
  92 >> This would also involve some kind of address filtering. I'll look into\r
  93 >> this and send patches later.\r
  94 >>\r
  95 >>> I have intentionally been guiet on this during the review process of the\r
  96 >>> other patches to not slow down the acceptance of the others. I have not\r
  97 >>> got enough time to look the implemenentation or think this last patch\r
  98 >>> further -- from the user interface point of view I recall seeing there\r
  99 >>> both useless features (but which might be warranted by implementation\r
 100 >>> simplicity) and missing features (but which might not be there due to \r
 101 >>> difficulty in implementation). Also, I am not sure whether the --filter-by\r
 102 >>> is good option (and options descriptive...)...\r
 103 >>\r
 104 >> I'd be interested in what are these "missing features".\r
 105 >\r
 106 > Last night when I tried to catch sleep I was also thinking of this...\r
 107 > ... let's see what I remember...\r
 108 >\r
 109 > First, Currently if we have addresses:\r
 110 >\r
 111 >  "Uni Que" <unique@example.org>\r
 112 >  "Uni Que" <Unique@Example.Org>\r
 113 >\r
 114 > I presume these are thought as a separate addresses -- and an option to\r
 115 > thought these as the same would be useful.\r
 116 \r
 117 Yes, this would correspond to --unique=addrfold or --unique=nameaddrfold\r
 118 from my patch.\r
 119 \r
 120 > but let's consider second set of addresses:\r
 121 >\r
 122 >  "Uni Que" <unique@example.org>\r
 123 >  "Uni Keko" <unique@example.org>\r
 124 >\r
 125 > Now, if there were an option to consider these 2 as the same, that would\r
 126 > hide user from one of the names -- It is clear that "Uni Que" is the right\r
 127 > one but if only "Uni Keko" (sleepyhead, that is) is shown user don't have\r
 128 > a choice to select the right one. I am not sure what the use case for\r
 129 > "uniquing" these 2 were.\r
 130 \r
 131 For example, when you are interested in the number of people involved in\r
 132 a discussion. You care only about the address and not about the names.\r
 133 Perhaps you'd like to see only the addresses in the output and not the\r
 134 names in this case, wouldn't you?\r
 135 \r
 136 > Finally (for now), 3rd set of addresses\r
 137 >\r
 138 >  "Uni Que" <unique@example.org>\r
 139 >  "Uni Que" <unique@foobar.invalid>\r
 140 >\r
 141 > Now, if there were an option to consider these 2 as same, and\r
 142 > user is then given "Uni Que" <unique@foobar.invalid> (which clearly is\r
 143 > the wrong one) I don't see the usefullness of this option...\r
 144 \r
 145 I agree. This would correspond to --unique=name. So I'll drop this\r
 146 option.\r
 147 \r
 148 -Michal\r