Re: Partial support for sorting the output of notmuch address

2021-12-20 Thread David Bremner
"inwit"  writes:

> On Sun Dec 19, 2021 at 7:18 PM CET, David Bremner wrote:
>> One of the annoyances with notmuch-address (and motivations for various third
>> party work-a-likes) is the fact that it does not output data in (descending)
>> frequency order. 
> Thanks, David! For those of us using company-prescient.el in emacs, this is 
> not
> really necessary. In the case of email addresses, I guess one could argue that
> the responsability for sorting could be of notmuch, but this works for me so
> far.

Sure. I'm just intesterted in bringing notmuch-address to rough feature
parity with some of the third party alternatives, particularly for
command line use.

> In any case, prescient's 'frecency' approach is better imho than frequency 
> only. 

Yeah, I can imagine that would be an improvement.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Partial support for sorting the output of notmuch address

2021-12-20 Thread inwit
On Sun Dec 19, 2021 at 7:18 PM CET, David Bremner wrote:
> One of the annoyances with notmuch-address (and motivations for various third
> party work-a-likes) is the fact that it does not output data in (descending)
> frequency order. 
Thanks, David! For those of us using company-prescient.el in emacs, this is not
really necessary. In the case of email addresses, I guess one could argue that
the responsability for sorting could be of notmuch, but this works for me so
far.

In any case, prescient's 'frecency' approach is better imho than frequency 
only. 

Regards,


___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Partial support for sorting the output of notmuch address

2021-12-19 Thread David Bremner
One of the annoyances with notmuch-address (and motivations for
various third party work-a-likes) is the fact that it does not output
data in (descending) frequency order.  This series adds that for
either --output=count or --deduplicate=address. This is because the
current --dedup=mailbox handling does not actually count the
occurences.

I see two ways to go here

1) Unify the handling of --dedup={mailbox,address}. This will probably
yield a performance hit for dedup=mailbox. How big probably depends on how many 
duplicates you have.
The main difference would be that the output would all arrive at the end, like 
with --dedup=address.

If people are using --dedup=mailbox for large queries, now is the time
to speak up. I noticed the builtin completion in notmuch-emacs is
already using --deduplicate=address, so probably no change there.

2) Apply something like this series, and deal with questions from
users confused by why only one of the deduplication options, or
output=count, sorts.

At least in my tests, there does not seem to be a noticable
performance hit for the current series. I'm also interested to know if
other people do notice such a hit.


___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org