Gnus and Emacs 20.3 and MIME

Gnus and Emacs 20.3 and MIME

[Kai Grossjohann]

What do you guys use for this combination?  I tried the latest TM I
could find (version 7.106 I think) (because SEMI-Gnus didn't quite
work right in Emacs 20.2).  I also tested the built-in MIME stuff
(using metamail.el) which works fine but is a little too aggressive:
it always plays all MIME parts; also, it doesn't allow me to write
MIME messages.

I just want a fairly workable solution that carries me over until Gnus
groks MIME.

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: Gnus and Emacs 20.3 and MIME

[François Pinard]

Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes:

> What do you guys use for this combination?  [...]  I just want a fairly
> workable solution that carries me over until Gnus groks MIME.

I peeked a bit around, and decided for `mime-compose.el' at message
composition time.  It only handles flat multipart (which I do not create
often anyway), and it looks like enough for now -- I only mean here that
I can live with that, not that I'm really satisfied.  For single part
messages like this one, a simple hook adds the necessary fields in the
header, so the various sendmails around here could do on-the-fly conversion
to quoted-printable for sites having older (or misconfigured :-) sendmails.

At message read time, I manage with a few simple Emacs functions I wrote,
which call a recent pretest of `recode' under the scene to do specific
decodings.  Sometimes, rarely, for more complex messages, I `o' the message
into a Babyl file and visit it, so to trigger `rmime.el'.  Once again,
I can live with that, even if not satisfied.

I used TM/SEMI for a while, not getting discouraged by installation
complexities, until they dropped Gnus support as a patch over Gnus.  TM/SEMI
is surely a very competent and featureful effort.  Despite I prefer being
collaborative, I did not like much that they distribute a parallel branch
of Gnus, and decided to stick more closely to the original Gnus development.

Moreover, if I dare to say, despite MIME undoubtly has its own complexities,
I think MIME should be nothing more than an aspect of Gnus, and all things
should be kept in proportion.  We should at least _aim_ that Gnus has a
MIME implementation which stays simple and non-obtrusive.  So, I'm ready to
stay a bit MIME-less until Gnus groks MIME, which hopefully will happen soon.

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: Gnus and Emacs 20.3 and MIME

[Jean-Yves Perrier]

As I almost never send MIME message (attachements,...), I use raw gnus to send mails and read them using gnus+tm7.106

This is a liveable workaround of course, although not completely satisfactory.

If gnus will support in native, it will be nice. I only hope that it will
also feature the advantages of MIME with recent protocols like IMAP which
let a user to fetch only the interesting MIME-part of a message from the
server (nnimap is under developpement but does not support this feature).

Of course it is always easier to speak about what we would like rather than
doing it :-)

My 0 cent worth comment,

-- 
Jean-Yves Perrier

Re: Gnus and Emacs 20.3 and MIME

[Edward J. Sabol]

> Sometimes, rarely, for more complex messages, I `o' the message
> into a Babyl file and visit it, so to trigger `rmime.el'.  Once again,
> I can live with that, even if not satisfied.

So `rmime.el' works with Emacs 20.3? Cool!

I'm rather partial to `rmime.el' and its simple, straightforward
implementation (especially compared to tm's complexity). I really hope Lars
takes a similar approach to implementing MIME in pgnus.

Re: Gnus and Emacs 20.3 and MIME

[Steinar Bang]

>>>>> "Edward J. Sabol" <sabol@alderaan.gsfc.nasa.gov>:

> I'm rather partial to `rmime.el' and its simple, straightforward
> implementation (especially compared to tm's complexity). I really
> hope Lars takes a similar approach to implementing MIME in pgnus.

I used to use rmime.el with VM, back in 1995.  But I found it too
simple and limitied, so I switched to mh-e which had better itegration 
with TM.

I tried using mew and its integrated MIME support, but I didn't like
the handling of the attachments.

I gradually moved from using Gnus with nnmh on the same folders I was
using MH-E on, and switching between the two, and moved all the way to 
Gnus in february of 1997, after getting TM to work in a satisfactory
manner with Gnus.

The fact that TM clashed with the 20.x series of GNU emacs, with MBSK, 
made me stay with 19.34 until my Solaris box crashed, and I switched
to a linux box with 20.2 MBSK.

Since that switch, I've been running late qgnus releases, with TM
7.106 on XEmacs 20.4.  This combination is something I would be happy
with if extension and modification was easier.  I haven't dug more
deeply into TM, because it is 
 1. no longer supported (I haven't had the time or inclination to do
    more than look *ligthly* into SEMI.  I couldn't get it to work at
    my first attempt at installing it, and I knew TM worked, so I
    dropped it)
 2. I'm hoping and waiting for integrated MIME support in Gnus


- Steinar

Re: Gnus and Emacs 20.3 and MIME

[SL Baur]

Steinar Bang <sb@metis.no> writes in ding@gnus.org:
 ...
> Since that switch, I've been running late qgnus releases, with TM
> 7.106 on XEmacs 20.4.  This combination is something I would be happy
> with if extension and modification was easier.  I haven't dug more
> deeply into TM, because it is 
>  1. no longer supported

Strictly speaking, that's not correct.  It is being supported in
XEmacs.  It will continue to be supported in XEmacs by me until Lars
ships a Gnus with MIME, and probably after that by the few remaining
people who use mh-e with tm.

The tm code may not be pretty to some, but it works and it is stable.

 ...
>  2. I'm hoping and waiting for integrated MIME support in Gnus

Me too.

Re: Gnus and Emacs 20.3 and MIME

[Steinar Bang]

>>>>> Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de>:

> I just want a fairly workable solution that carries me over until
> Gnus groks MIME.

Maybe we should start collecting requirements for this MIME
implementation?  Good requirements always give a clearer idea of how
things should be implemented.

I would primarily like to see functional requirements on the form "I
would like to...".

Here are some of mine:
 - I would like automatic decoding of q-b or base64 encoded text/plain 
   message parts
 - I would like to view images (JPEG, GIF, PNG) inline in the message
 - I would like a simple way to save them
 - I would like a simple way of navigating through a multipart
   message, and view and save the parts
(I rather like the behaviour of TM in Xemacs for the above)

- I would like to see text/html message parts formatted inline in the
  message (using W3, I guess), both where they are the only
  alternative, and where they are part of a multipart/alternative
- I would like to be easily able to toggle between text/plain and
  text/html parts of a multipart/alternative
- I would like to be able to reply to a text/html message part as if
  it had been a text/plain message (ie. I would like to see the HTML
  formatted into plain text before it's taken into a *message* buffer
  and quoted)
- I would like attached MSWord documents to be shown inline as the
  results of catdoc or other filter, while keeping it easy to save the
  MSWord file to disk 

Those are the ones I can think about at the top of my head.  They're
based in the desire to handle the messages people send to me
(typically composed in Netscape or MSOutlook) as automatically as
possible. 

There's a bit of prestige involved, as well as a desire to handle this 
stuff without manual intervention.  I'm tired of hearing that I'm
backwards and that I should "get a *modern* email program".

I guess the things larsi will implement first, are utilities for
parsing and decoding a MIME message.  What we then need is a good
modular mechanism for running things through filters and displaying
them in the message.  Then people can start writing their own filters.

The one thing in my "functional requirements" that cannot be handled
this way, is the stuff surrounding HTML and multipart/alternative.


- Steinar

Re: Gnus and Emacs 20.3 and MIME

[Alan Shutko]

>>>>> "S" == Steinar Bang <sb@metis.no> writes:

S> I would primarily like to see functional requirements on the form
S> "I would like to...".

S> I would like a simple way to save them

I would like to be prompted for directory and filename.  That's one
area that TM/SEMI really upset me.

Other than that, you've covered everything I want!

-- 
Alan Shutko <ats@acm.org> - By consent of the corrupted
"I am Archie of Borg. Your will be da first one 'similated, meathead!"

Re: Gnus and Emacs 20.3 and MIME

[Andy Eskilsson]

/ Alan Shutko <ats@acm.org> wrote:
| >>>>> "S" == Steinar Bang <sb@metis.no> writes:
| 
| S> I would primarily like to see functional requirements on the form
| S> "I would like to...".
| 
| S> I would like a simple way to save them
| 
| I would like to be prompted for directory and filename.  That's one
| area that TM/SEMI really upset me.

UHm, let it be configurable, so you either can choose a standard
subdir to extract files to (without asking) or be asked with some
special directory as default, or 'current'. Or the final setting, ask
for everything, even the shoe-size of my grand-children (well I don't
have any yet but..)..


	/Andy

Re: Gnus and Emacs 20.3 and MIME

[Jan Vroonhof]

Steinar Bang <sb@metis.no> writes:

> I would primarily like to see functional requirements on the form "I
> would like to...".

Here are some of the ones of the type "$$@#@, I wish TM did that"

1. When extracting the contents of some part to a file, ASK for a
   filename. Make the origional name the default in some directory
   which should be settable using elisp.
2. Be able to do everthing in elisp only. Only call external
   executables as a speedup option.
3. Be able to extract a part to a buffer.

Jan

Re: Gnus and Emacs 20.3 and MIME

[François Pinard]

Steinar Bang <sb@metis.no> writes:

> Here are some of mine:

All these desiderata are quite sensible.  One thing looks more difficult
for those using Emacs instead of XEmacs:

>  - I would like to view images (JPEG, GIF, PNG) inline in the message

Emacs 20.5 should have inlined pictures, but it would be fun to find some
solution for Emacs users, before we get there.

> The one thing in my "functional requirements" that cannot be handled
> this way, is the stuff surrounding HTML and multipart/alternative.

I presume the best bet is automatically using the richest format possible
in a given environment, or at least, have user options stating preferences.
Manual intervention could be required to alter the choice (a bit like there
are washing commands to alter presentation after the fact, even if these
commands are hook-able), but I would not say that having such commands for
selection among alternative MIME parts would make Gnus less interesting.
All the contrary: it's better having a choice than none.  Yet, selection
among alternative parts should be automated by default.

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: Gnus and Emacs 20.3 and MIME

[Kai Grossjohann]

>>>>> François Pinard <pinard@iro.umontreal.ca> writes:

  > Emacs 20.5 should have inlined pictures, but it would be fun to
  > find some solution for Emacs users, before we get there.

set-face-stipple, I say 8-)

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: Gnus and Emacs 20.3 and MIME

[SL Baur]

ois Pinard <Fran> writes in ding@gnus.org:

> Steinar Bang <sb@metis.no> writes:
>> Here are some of mine:

> All these desiderata are quite sensible.  One thing looks more difficult
> for those using Emacs instead of XEmacs:

>> - I would like to view images (JPEG, GIF, PNG) inline in the message

> Emacs 20.5 should have inlined pictures, but it would be fun to find some
> solution for Emacs users, before we get there.

What more can you do than what tm already does?  You get an inline
image if the editor supports it, otherwise you get a button to click
on to extract the image to a file or play it on an external viewer.

Re: Gnus and Emacs 20.3 and MIME

[Alan Shutko]

>>>>> "sb" == SL Baur <steve@xemacs.org> writes:

sb> ois Pinard <Fran> writes in ding@gnus.org:

>> Emacs 20.5 should have inlined pictures, but it would be fun to
>> find some solution for Emacs users, before we get there.

sb> What more can you do than what tm already does?

pbmtoascii

-- 
Alan Shutko <ats@acm.org> - By consent of the corrupted
The more things change, the more they stay insane.

Re: Gnus and Emacs 20.3 and MIME

[SL Baur]

Steinar Bang <sb@metis.no> writes in ding@gnus.org:
 [nice requirements ...]
> There's a bit of prestige involved, as well as a desire to handle this 
> stuff without manual intervention.  I'm tired of hearing that I'm
> backwards and that I should "get a *modern* email program".

It doesn't get any more modern than Gnus+TM on XEmacs (IMNSHO).



I would add to the list:

Decoding MIME attachments to files should work the same as uudecoding
works.  In other words, if you tick a number of messages, some of
which are uuencoded and some of which are MIME encoded, and pick one
of the batch uudecode functions, all messages should have their
contents extracted to files.


I'd like to see a similar level of Mule support as is currently
implemented in tm.

Re: Gnus and Emacs 20.3 and MIME

[Hrvoje Niksic]

SL Baur <steve@xemacs.org> writes:

> Steinar Bang <sb@metis.no> writes in ding@gnus.org:
>  [nice requirements ...]
> > There's a bit of prestige involved, as well as a desire to handle this 
> > stuff without manual intervention.  I'm tired of hearing that I'm
> > backwards and that I should "get a *modern* email program".
> 
> It doesn't get any more modern than Gnus+TM on XEmacs (IMNSHO).

I beg to differ.  TM's user interface is simply horrible; its
crockishness has been discussed many times on xemacs-beta.  Whatever
native Gnus MIME support does will likely end up being much better.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Don't hit a man when he's down -- kick him; it's easier.

Re: Gnus and Emacs 20.3 and MIME

[Michael Harnois]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Whatever native Gnus MIME support does will likely end up being much
> better.

If it doesn't happen in our lifetimes, though, it won't make a lot of
difference. 

-- 
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA 
mharnois@sbt.net                      aa0bt@aa0bt.ampr.org 
"There can be no transforming of darkness into light and 
 of apathy into movement without emotion." - Carl Jung

Re: Gnus and Emacs 20.3 and MIME

[Kees de Bruin]

Steinar Bang writes:

> >>>>> Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de>:
> 
> > I just want a fairly workable solution that carries me over until
> > Gnus groks MIME.
> 
> Maybe we should start collecting requirements for this MIME
> implementation?  Good requirements always give a clearer idea of how
> things should be implemented.

I only hear people talking about TM for handling MIME, but what about the
way MIME is handled in VM. Mainly because of the full integration of the
MIME support in VM, the user doesn't have to configure anything at all and
it still works as expected.

-- 
Kees de Bruin                                             Software Engineer
---------------------------------------------------------------------------
E-mail:  kees_de_bruin@tasking.com                      Tasking Software BV
Voice:   +31-33-455 85 84                               Plotterweg 31
Fax:     +31-33-455 00 03                               3821 BB  Amersfoort
WWW:     http://www.tasking.com                         The Netherlands
--------[ Give me the Luxuries, and the Hell with the Necessities! ]-------

Re: Gnus and Emacs 20.3 and MIME

[Hrvoje Niksic]

Kees de Bruin <kees_de_bruin@tasking.com> writes:

> I only hear people talking about TM for handling MIME, but what
> about the way MIME is handled in VM. Mainly because of the full
> integration of the MIME support in VM, the user doesn't have to
> configure anything at all and it still works as expected.

True.  I would recommend to Lars to look at VM's MIME support and see
if he likes that.  Implementing something similar (at least at the UI
level) would be a *very* good start.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Silence!" cries Freydag. "I did not call thee in for a consultation!"
"They are my innards! I will not have them misread by a poseur!"

Re: Gnus and Emacs 20.3 and MIME

[Steinar Bang]

>>>>> Hrvoje Niksic <hniksic@srce.hr>:

> True.  I would recommend to Lars to look at VM's MIME support and see
> if he likes that.  Implementing something similar (at least at the UI
> level) would be a *very* good start.

Hm... how about if people who know and like VM's MIME support save
larsi the work and trouble and summarize what they like about it as
functional requirements.

Just my 77 øre...

Re: Gnus and Emacs 20.3 and MIME

[Kees de Bruin]

Hrvoje Niksic writes:

> Kees de Bruin <kees_de_bruin@tasking.com> writes:
> 
> > I only hear people talking about TM for handling MIME, but what
> > about the way MIME is handled in VM. Mainly because of the full
> > integration of the MIME support in VM, the user doesn't have to
> > configure anything at all and it still works as expected.
> 
> True.  I would recommend to Lars to look at VM's MIME support and see
> if he likes that.  Implementing something similar (at least at the UI
> level) would be a *very* good start.

In a private discussion with Steinar Bang I promised to post a list of MIME
functions the VM mail reader supports. The VM mail reader has support for
MIME since version 6.xx and, as far as I know, in the current version of VM
(6.61) the following MIME capabilities are present (or at least used by
me):

MIME encoding:

- Attachments are possible with whatever encoding the user wants. Also,
  based on the extension of the file, VM can guess the correct encoding to
  use. No mailcap/mimetypes support.

- Encoding can be done using internal ELisp functions, or via external
  programs.

- Sending multiple messages as a single MIME digest.

MIME decoding:

- The user can configure what MIME types should be displayed inline
  (meaning that it is either displayed in a buffer or directly via an
  external program).

- For non-inline MIME types buttons are generated the user can use to save
  the MIME part to a file, or open it in some external viewer.

- Alternative display of MIME messages: plain text (no conversions), using
  inline display, or all buttons.

- Handling of multipart messages (am I correct here, I never tried this).

- Decoding can be done using internal ELisp functions, or via external
  programs.

- Handling of MIME digests.

I have probably missed some other MIME functions, but the above are the
things I use regularly. If there are other that use VM maybe they can
update the above list.

Greetings,

-- 
Kees de Bruin                                             Software Engineer
---------------------------------------------------------------------------
E-mail:  kees_de_bruin@tasking.com                      Tasking Software BV
Voice:   +31-33-455 85 84                               Plotterweg 31
Fax:     +31-33-455 00 03                               3821 BB  Amersfoort
WWW:     http://www.tasking.com                         The Netherlands
--[ In memory, everything seems to happen to music -- Tennessee Williams ]-

Re: Gnus and Emacs 20.3 and MIME

[Jake Colman]

I hope that pgnus will not suffer from the "not invented here" syndrome and
will make use of as much as is already available as it can.  It just would
seem a shame if we could not benefit from the work thet VM or SEMI has
already done with regards to MIME support.

Do we have any form of time frame in which to expect the rudiments of MIME
support in an early pgnus?

-- 
Jake Colman                     

Principia Partners LLC                  Phone: (201) 946-0300
Harborside Financial Center               Fax: (201) 946-0320
902 Plaza II                           Beeper: (800) 505-2795
Jersey City, NJ 07311                  E-mail: colman@ppllc.com
                                       E-mail: jcolman@jnc.com
                                          web: http://www.ppllc.com

Re: Gnus and Emacs 20.3 and MIME

[Steinar Bang]

>>>>> Jake Colman <colman@ppllc.com>:

> I hope that pgnus will not suffer from the "not invented here"
> syndrome and will make use of as much as is already available as it
> can.  It just would seem a shame if we could not benefit from the
> work thet VM or SEMI has already done with regards to MIME support.

The VM stuff is out, as Kyle Jones refuses to sign his code over to
FSF, and this is neccessary for being included into the GNU emacs
distribution (as Gnus is meant to be).

I haven't looked at SEMI, but I belive TM is more complex than what
larsi aims for.  Also well integrated native MIME support will be
designed differently to MIME support that is meant to work for a
multitude of MUAs.

Re: Gnus and Emacs 20.3 and MIME

[Jean-Yves Perrier]

Other point:

In some MIME type, like vcard, there is a possible to make special URL
beginning with cid:...

These relate to other MIME attachement of the same message. It would be
nice for the people developping MIME types extension that Gnus provides
function to handles these URL smoothly.

-- 
Jean-Yves Perrier

Re: Gnus and Emacs 20.3 and MIME

[Hrvoje Niksic]

Jake Colman <colman@ppllc.com> writes:

> I hope that pgnus will not suffer from the "not invented here"
> syndrome and will make use of as much as is already available as it
> can.  It just would seem a shame if we could not benefit from the
> work thet VM

This is exactly what will happen.  Stallman requires the code to be
included in FSF Emacs (which includes Gnus) to be assigned to the FSF, 
and Kyle will never do that with VM.

> or SEMI has already done with regards to MIME support.

I hope Lars will not reuse the code in TM and SEMI.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Manic depression is cool...  your body can make its own drugs.

Re: Gnus and Emacs 20.3 and MIME

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> > or SEMI has already done with regards to MIME support.
> 
> I hope Lars will not reuse the code in TM and SEMI.

As noted the VM code is off limits.  I would like to use the code from
TM and SEMI, but I just don't understand much of it.  The most likely
suspects for pilfering are, uh, rmime and the mime-compose thing
François mentioned.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus and Emacs 20.3 and MIME

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > > or SEMI has already done with regards to MIME support.
> > 
> > I hope Lars will not reuse the code in TM and SEMI.
> 
> As noted the VM code is off limits.

What does "off limits" mean?

With respect to VM, I would like you to reuse the design decisions,
where possible and appropriate, rather than the actual code.

> The most likely suspects for pilfering are, uh, rmime and the
> mime-compose thing François mentioned.

I'm not sure how good idea it is to reuse these libraries, but that's
your decision to make.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Your lucky number today is 29842924728.  Look for it everywhere.

Re: Gnus and Emacs 20.3 and MIME

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> > As noted the VM code is off limits.
> 
> What does "off limits" mean?

Kyle Jones doesn't sign his code off to the FSF.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus and Emacs 20.3 and MIME

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > > As noted the VM code is off limits.
> > 
> > What does "off limits" mean?
> 
> Kyle Jones doesn't sign his code off to the FSF.

Oh, I know that.

As I said before, I am advocating VM's good UI design rather than the
possibility of reuse of its code.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Try to use "ad nauseam" at least once per flame. It doesn't mean
anything; but it gives that polished feel to your postings.

Re: Gnus and Emacs 20.3 and MIME

[Dave Love]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

 Lars> The most likely suspects for pilfering are, uh, rmime and the
 Lars> mime-compose thing François mentioned.

AFAIR the TM composition is derivative of Umeda's mime.el (which I
think is assigned).  You might look at that (1995 vintage), but
obviously something of his would need one or two small tweaks.

Isn't W3 always a good suspect?  You can beat a confession out of it
to a surprising number of things.

Re: Gnus and Emacs 20.3 and MIME

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de>:
>> I just want a fairly workable solution that carries me over until
>> Gnus groks MIME.

> Maybe we should start collecting requirements for this MIME
> implementation?  Good requirements always give a clearer idea of how
> things should be implemented.

> I would primarily like to see functional requirements on the form "I
> would like to...".

> Here are some of mine:

A new point:

 - I would like the MIME support to cooperate with the upcoming
   nnimap, in such a way that loading of attachments can be delayed
   until you actually wish to show or save it (delay the download of
   that 5MB PowerPoint file your boss sent you (real example: it
   happened to me today) until you can plug your laptop into the LAN at
    work)

For more info on nnimap, see
	http://www.ccs.neu.edu/software/contrib/gnus/#Q4_13
and follow the link on to Simon Josefsson's web page.