[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ANNOUNCE] mailaprop: modern popup-style autofill for email addresse

From: Karl Fogel
Subject: Re: [ANNOUNCE] mailaprop: modern popup-style autofill for email addresses
Date: Mon, 15 Jan 2018 17:31:25 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

"John Wiegley" <address@hidden> writes:
>KF> Hi. I wrote a new package, 'mailaprop', that provides popup-style autofill
>KF> for email addresses in recipient headers of message composition buffers.
>If you want a nice source of candidates, I wrote this unpublished package:
>It watches who you write to, and who you read e-mail from (if you hook it into
>Gnus), and stores them all in an SQLite database with timestamps. It then lets
>you query for a candidate list. I use it via message-x.

Thanks, John.  That looks handy.

To be useable by mailaprop, it would need to remember the datestamp of the 
message the address was harvested from (or at least remember the date of the 
most recent message that address was harvested from), and keep separate counts 
for how often the address had been sent to and how often it had been received 

This is because the order in which addresses are offered in autofill matters.  
The most likely candidate should be at the top, the next-most-likely underneath 
it, and so on.  Right now, the inputs to the likelihood-calculating algorithm 
are the last-seen date, the total sent-to count, and total received-from count. 
 I could make things fancier later, but for now those are the inputs.

Would those pieces of information be useful for message-x and other integratees 
of gnus-harvest too?  Obviously, that information would be pretty easy to 
harvest.  If mailaprop and message-x could share inputs, that'd be nice.

By the way, mailaprop's current solution to the problem of gathering input data 
is a standalone Python script.  It crawls all your mbox files (other formats to 
be supported in the future, I hope) and builds the autofill database from that. 
 I've just added a paragraph to the README.md explaining that it could take 
input from other sources too, and linking to this discussion.

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]