On Fri, Jan 09 2015, Michal Sojka <sojkam1@fel.cvut.cz> wrote: > Hi, > > sorry for longer response time :) > > On Thu, Jan 01 2015, Tomi Ollila wrote: >> On Wed, Dec 31 2014, David Bremner <david@tethera.net> wrote: >> >>> Michal Sojka <sojkam1@fel.cvut.cz> 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" <unique@example.org> "Uni Que" <Unique@Example.Org> 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" <unique@example.org> "Uni Keko" <unique@example.org> 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" <unique@example.org> "Uni Que" <unique@foobar.invalid> Now, if there were an option to consider these 2 as same, and user is then given "Uni Que" <unique@foobar.invalid> (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