> Thinking about it again, I believe that we should introduce a single
> variable like vm-mailing-list-options-alist to control the various
> options. It could look like this:
>
> '(("\\`emacs-devel@gnu\\.org\\'" mft)
> (".*@lists\\.launchpad\\.net\\'" mft)
> ("\\`reply-to-mangling@list\\.example\\'" mft mrt ignore-reply-to))
>
> Open question: Should the CAR elements be regexps or strings? Regexps
> would be more flexible and allow matching for several lists at one
> server, and are already used with vm-reply-ignored-reply-tos. Strings
> would be simpler of course.
Good idea. Regexps would be consistent with other such alists VM
already has. I myself actually put strings in them. Even though the
'.'s have semantics, they usually work fine.
Ulrich Müller writes:
> Thinking about it again, I believe that we should introduce a single list-options- alist to control the various emacs-devel@ gnu\\.org\ \'" mft) \.launchpad\ \.net\\ '" mft) to-mangling@ list\\. example\ \'" mft mrt ignore-reply-to)) ignored- reply-tos. Strings
> variable like vm-mailing-
> options. It could look like this:
>
> '(("\\`
> (".*@lists\
> ("\\`reply-
>
> Open question: Should the CAR elements be regexps or strings? Regexps
> would be more flexible and allow matching for several lists at one
> server, and are already used with vm-reply-
> would be simpler of course.
Good idea. Regexps would be consistent with other such alists VM
already has. I myself actually put strings in them. Even though the
'.'s have semantics, they usually work fine.
Cheers,
Uday