user.other_email wildcard config?

user.other_email wildcard config?

[Charles Cazabon]

Hi,

To get notmuch to correctly identify me as the sender or recipient of
messages, I need to configure my primary and alternate email addresses -
however, I use extension addresses extensively (such as for subscribing to
this list...).  So in theory, I have an indeterminate number of addresses that
are "me", and in practice, it's at least several hundred I've actually used
(and adding new ones a few times a month on average).

Listing all of these addresses in the other_email configuration would be
painful, and would require constant maintenance as I use new addresses with
new businesses, mailing lists, etc.

I've searched the list archives but have only found references to setting
user.other_email to a list of actual addresses.  Is there a way to have a
wildcard, glob, or regex serve as the configuration for other_email?  Have I
missed something in the documentation?

Thanks,

Charles
-- 
------------------------------------------------------------------
Charles Cazabon              <charlesc-notmuchmail.org@pyropus.ca>
Software, consulting, and services available at http://pyropus.ca/
------------------------------------------------------------------

Re: user.other_email wildcard config?

[David Bremner]

Charles Cazabon <charlesc-notmuchmail.org@pyropus.ca> writes:

> I've searched the list archives but have only found references to setting
> user.other_email to a list of actual addresses.  Is there a way to have a
> wildcard, glob, or regex serve as the configuration for other_email?  Have I
> missed something in the documentation?

No, you didn't miss anything; the code currently assumes that is a list
of literal email addresses. I guess the emacs front-end would require
some adaptation to change that to a list of regexes, but probably not a
heroic amount. The function address_match in notmuch-reply.c would also
need to be adjusted.

Re: user.other_email wildcard config?

[Charles Cazabon]

David Bremner <david@tethera.net> wrote:
> Charles Cazabon <charlesc-notmuchmail.org@pyropus.ca> writes:
> 
> > Is there a way to have a wildcard, glob, or regex serve as the
> > configuration for other_email?
>
> [...] the code currently assumes that is a list of literal email addresses.
> I guess the emacs front-end would require some adaptation to change that to
> a list of regexes, but probably not a heroic amount. The function
> address_match in notmuch-reply.c would also need to be adjusted.

Thanks for the reply, David.  I'm not an Emacs user, just using notmuch with
mutt.  If this functionality isn't on the roadmap, I can give it a crack
myself - but my time for working on other projects seems to be at a premium
these days.  If I get anywhere with it, I'll send it in.

Charles
-- 
------------------------------------------------------------------
Charles Cazabon              <charlesc-notmuchmail.org@pyropus.ca>
Software, consulting, and services available at http://pyropus.ca/
------------------------------------------------------------------

Re: user.other_email wildcard config?

[David Bremner]

Charles Cazabon <charlesc-notmuchmail.org@pyropus.ca> writes:

> David Bremner <david@tethera.net> wrote:
>> Charles Cazabon <charlesc-notmuchmail.org@pyropus.ca> writes:
>> 
>> > Is there a way to have a wildcard, glob, or regex serve as the
>> > configuration for other_email?
>>
>> [...] the code currently assumes that is a list of literal email addresses.
>> I guess the emacs front-end would require some adaptation to change that to
>> a list of regexes, but probably not a heroic amount. The function
>> address_match in notmuch-reply.c would also need to be adjusted.
>
> Thanks for the reply, David.  I'm not an Emacs user, just using notmuch with
> mutt.  If this functionality isn't on the roadmap, I can give it a crack
> myself - but my time for working on other projects seems to be at a premium
> these days.  If I get anywhere with it, I'll send it in.

I hear you. I am also very slow on notmuch patch reviewing at the
moment, but we will get there in the end.

d