Re: Gnus and Emacs 20.3 and MIME

[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:
 - 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