Re: For 1.5.8: notalternates functionality
Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx> wrote:
> > The attached patch allows users to exclude portions of the namespace
> > matched by alternates.
> Mhh... I think the plan after 1.5.7 was to model unalternates after
> the ignore/unignore combo, where we not only use unignore to remove
> things from the ignore list, but also to add things to an unignore
> list.
I'm not entirely sure I'm clear on the meaning of this. I think you mean
that, for example, `unnotalternates foo` would first check whether "foo" was
one of the patterns given in `notalternates`; if so, it would simply remove
that pattern. If it was not one of the notalternates patterns, it would then
add it to the list of unnotalternates patterns.
Is that an accurate summary?
> If we want to do the same for alternates/unalternates, then we should, for
> the purpose of consistency, also do it to the mailing list handling. This
> would call for some generic (but not too difficult) changes in init.h and
> init.c.
If there's a general need for this kind of three-way matching/unmatching, then
yes, it makes sense to have a generic mechanism and use it for every instance.
> I'm wondering, though, if it wouldn't make the already-complex
> mailing list handling unusable.
I haven't looked at any of the mailing-list-specific code. The configuration
interface for mailing lists is dead simple. Other than that -- I'm not sure
how this would apply to mailing list handling?
> Thoughts?
I'm not too particular on how my particular problem is solved, just that it is
solved. I'll restate the problem I was having with vanilla mutt, for
clarification:
I have a couple of domains for mail. I use different email addresses for
everything (each mailing list I'm on, each company I do business with, each
web feedback form I fill out, etc), so basically the pattern
^.*\@example\.org$ would be perfect for me in `alternates`, except ...
I have a few portions of that namespace that I've given to my wife, and might
give to other family members. So when I sent mail to my wife, both the From:
and To: addresses were matched by the above alternates pattern, and mutt would
display /my/ name in the index view with %F in index_format. It makes life
difficult.
Crafting a regular expression (or series of regular expressions) to match all
of ^.*\@example\.org$ except N other unique-prefix portions of it would be a
horrible task. It seemed to me that it would be much easier to simply add a
list of expressions that negated the match, and that led me to create
`notalternates`. I didn't need `unnotalternates`, but I added it for
parallelism with `unalternates` (which I also don't use). Now I can just do:
alternates ^.*@(example\.org|example\.net)$
notalternates ^(wife|...)(-extension)?@example\.org$ ...
and everything works the way it should, and %F shows my recipient, even when I
send mail to one of the other addresses in my domains. I guess I have never
looked into this three-way version (if I descirbed it correctly) because I've
never found unalternates useful. My original notalternates patch didn't even
include unnotalternates; I added it when someone else complained about its
lack or parallelism with alternates/unalternates.
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <muttdev@xxxxxxxxxxxxxxxxxxxx>
-----------------------------------------------------------------------