Re: new Mail-Followup-To patch...please take a look...

[prj@po.cwru.edu (Paul Jarc)]

"Matt Armstrong" <matt@lickey.com> wrote:
> And we could save a copy of 'gnus-parameters' and make sure the
> saved copy is equal to the current value.

Or even eq.  That might trigger some unnecessary regeneration in some
odd cases, but more often, it would speed up the comparison.

> message.el can't call into gnus or use a gnus variable, but surely
> gnus could set a variable on behalf of message.el?
> 
> E.g. there'd be message-subscribed-addresses, and
> message-subscribed-addresses-from-mua.  The former is a user setting,
> the latter is set by the mua (perhaps buffer local).

If Gnus sets a separate variable, then we need yet another variable to
control whether Gnus should do that.

Here's another idea: have a gnus function which can be an entry in
message-subscribed-address-functions.  This function collects to-list
and to-address parameters and, for speed, caches them in an internal
(i.e., not for users to mess with, but still global) variable.  Now we
change the default for message-subscribed-address-functions:
(defvar message-subscribed-address-functions '(ignore))
Gnus adds its function to m-s-a-f at startup, but only if the existing
value is this default.  If the user wants to disable the Gnus
function, they set m-s-a-f to (the more intuitive) nil.

This seems perhaps too clever for its own good, but it means that the
user's setting sticks, with no extra work, which I like.


paul