Excessively Painful Forwards

Excessively Painful Forwards

[Chris Richards]

Howdy.

S o m forwards a message.  When I tried to forward a mutli-part
message which contain a largish attachment, it took quite a well to
render the *mail* buffer.  xemacs climbed to 97% of the CPU and 49% of
available memory.

When it finished churning, I realized why... the entire attachment was
shown encoded in the buffer.

Is there away to _hide_ such attachments?  Knowing they are there in
buttonized form would be nice--anything to speed up the access.

On a related note, gnus hangs my xemacs session when it
checks/parses/splits news and mail.  Is this a limitation of the
architecture or this there a way to background these tasks?

Cheers,
cjr

Re: Excessively Painful Forwards

[Kai Großjohann]

Chris Richards <cjr@netpliance.net> writes:

> On a related note, gnus hangs my xemacs session when it
> checks/parses/splits news and mail.  Is this a limitation of the
> architecture or this there a way to background these tasks?

In principle, it is possible to background these tasks, but it is very
hard to code due to the limited form of (cooperative) multitasking
implemented in Emacs.

You would have to recode Gnus such that it does its work in small
chunks: when you hit `g', the first chunk is scheduled for a time when
Emacs is idle.  Just before finishing, the first chunk schedules a
second chunk for a time when Emacs is idle, and so on.  This would be
a decidedly nontrivial undertaking.

kai
-- 
~/.signature: No such file or directory

Re: Excessively Painful Forwards

[Greg Stark]

On the other hand it would not be hard to do this for network-bound interfaces
such as nntp. In fact the basic infrastructure in nntp.el is there already,
all that's needed now is support from gnus itself in the form of an
asynchronous backend interface.

I have a backend here that uses recursive edits to demonstrate how useful this
would be and it's proven extremely useful. Unfortunately recursive edits don't
scale as a way to do this. In particular they wouldn't work well if multiple
backends tried to use this technique... 

It might be tricky but basically what gnus needs is an option to provide to
the backend that would be a closure to call when the operation was finished.
Then the backend could schedule all its work and return immediately. Taking
care of the processing of data in callbacks, calling the closure when it's
finished. 

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Chris Richards <cjr@netpliance.net> writes:
> 
> > On a related note, gnus hangs my xemacs session when it
> > checks/parses/splits news and mail.  Is this a limitation of the
> > architecture or this there a way to background these tasks?
> 
> In principle, it is possible to background these tasks, but it is very
> hard to code due to the limited form of (cooperative) multitasking
> implemented in Emacs.
> 
> You would have to recode Gnus such that it does its work in small
> chunks: when you hit `g', the first chunk is scheduled for a time when
> Emacs is idle.  Just before finishing, the first chunk schedules a
> second chunk for a time when Emacs is idle, and so on.  This would be
> a decidedly nontrivial undertaking.
> 
> kai
> -- 
> ~/.signature: No such file or directory
> 

-- 
greg

Re: Excessively Painful Forwards

[Kai Großjohann]

Greg Stark <gsstark@mit.edu> writes:

> It might be tricky but basically what gnus needs is an option to provide to
> the backend that would be a closure to call when the operation was finished.
> Then the backend could schedule all its work and return immediately. Taking
> care of the processing of data in callbacks, calling the closure when it's
> finished. 

Note that this is not quite sufficient for, eg, mail splitting.  Here,
you get a large ~/Mail/Incoming file and there is no natural division
between chunks of work, like in process filters, so what it comes down
to is that you have to do that yourself.

And that's all I had been trying to say.  Maybe `very hard' was an
exaggeration, but, well...

kai
-- 
The birch trees flay way too low these days.