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

["Matt Armstrong" <matt@lickey.com>]

prj@po.cwru.edu (Paul Jarc) writes:

> Josh Huber <huber@alum.wpi.edu> wrote:
>> prj@po.cwru.edu (Paul Jarc) writes:
>>> I had hoped that MFT would be enabled by default: existing
>>> configurations would automatically get MFT when sending to any
>>> to-address or to-list address.  [...]  But if that's not going to
>>> be the case, then this chunk might as well be a hook function.
>>> It'll just be one extra line needed in .gnus to enable MFT.
>> 
>> Well, that's what I suggested.
>> 
>> I think something like:
>> 
>> (setq message-subscribed-addresses
>>       (gnus-find-subscrbied-addresses))
>> 
>> in the .gnus file would be an ok thing to have users do, wouldn't it?
> 
> The distance between n and n+1 is at a maximum when n=0.  If we have
> to add anything at all to our individual .gnus files to enable MFT,
> then I don't think it matters much if we have to add a little more
> instead of a little less.  Since it's possible to do it as a hook,
> it seems cleaner to do it that way, assuming we've given up on
> getting it completely for free.

I haven't given up on getting MFT for free (on by default).  Per's
example of using to-address and to-list for non-list addresses are an
example of a power user config.  I think providing a 'not-subscribed
parameter just for Per is okay.  ;-)

In other words, I think it is okay to assume that all to-list and
to-address parameters are "subscribed," but provide a way out for the
Gnus power users.


>> The problem with this is, this search function appears to be
>> expensive enough that I wouldn't want it as a default...
> 
> If it only happens once per Gnus session, that shouldn't be a
> problem, I think.

Caching the result is fine.

It'd be nice if changing group parameters would magically cause the
list to be regenerated.  Setting a "dirty" flag when group params have
been edited is probably easy enough.  And we could save a copy of
'gnus-parameters' and make sure the saved copy is equal to the current
value.


> message.el shouldn't explicitly use a gnus- function, and gnus*.el
> would have a hard time deciding when and whether to populate
> message-subscribed-addresses with the to-list and to-address
> parameters.  If not for that, I think we could get MFT completely
> for free.

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).


-- 
matt