Unnecessary hashcash computations

Unnecessary hashcash computations

[Bjørn Mork]

I'm using the async hashcash functionality, which works very well most
of the time.  But there is one situation where it could be improved
(maybe - there should of course have been a patch here if this was
easy...)

Sometimes I do a wide reply to a mail originally sent to a large
number of recepients, where I remove some recepients before writing
the reply.  In this case Gnus will continue to compute X-Hashcash
fields for *all* the original recepients, regardless of the real
content of the To and Cc fields.  That's a lot of wasted CPU cycles
;-)

Does anyone see how this could be avoided, still keeping the async
computation?  If we at the same time could get async hashcash
computation for new recepients, then that would of course be even
better.



Bjørn
-- 
I don't want to hear about your operation.

Re: Unnecessary hashcash computations

[Andreas Seltenreich]

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]

Bjørn Mork writes:

> Does anyone see how this could be avoided, still keeping the async
> computation?  If we at the same time could get async hashcash
> computation for new recepients, then that would of course be even
> better.

I don't have a solution for the former, but I have the following in my
.gnus.el to take care of the latter:


[-- Attachment #2: Type: application/emacs-lisp, Size: 302 bytes --]

[-- Attachment #3: Type: text/plain, Size: 223 bytes --]


However, I'm not sure what the canonical way to integrate this into
Gnus would be.  Introducing a message-goto-body-hook might be more
general, but this wouldn't allow for the prefix arg to be specified.

regards,
andreas