From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/16278 Path: main.gmane.org!not-for-mail From: Steinar Bang Newsgroups: gmane.emacs.gnus.general Subject: Re: Gnus and Emacs 20.3 and MIME Date: 25 Aug 1998 16:45:38 +0200 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1035155171 26774 80.91.224.250 (20 Oct 2002 23:06:11 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 23:06:11 +0000 (UTC) Return-Path: Original-Received: from gwyn.tux.org (gwyn.tux.org [207.96.122.8]) by altair.xemacs.org (8.9.1/8.9.1) with ESMTP id HAA19780 for ; Tue, 25 Aug 1998 07:48:33 -0700 Original-Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by gwyn.tux.org (8.8.8/8.8.8) with ESMTP id KAA14472 for ; Tue, 25 Aug 1998 10:49:45 -0400 Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by sina.hpc.uh.edu (8.7.3/8.7.3) with ESMTP id JAK11788; Tue, 25 Aug 1998 09:48:07 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 25 Aug 1998 09:46:28 -0500 (CDT) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [209.195.19.139]) by sina.hpc.uh.edu (8.7.3/8.7.3) with ESMTP id JAA11765 for ; Tue, 25 Aug 1998 09:46:19 -0500 (CDT) Original-Received: from viffer.oslo.metis.no (viffer.oslo.metis.no [195.0.254.249]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id KAA21248 for ; Tue, 25 Aug 1998 10:46:11 -0400 (EDT) Original-Received: (from sb@localhost) by viffer.oslo.metis.no (8.8.7/8.8.7) id QAA19958; Tue, 25 Aug 1998 16:45:38 +0200 Original-To: ding@gnus.org In-Reply-To: Kai Grossjohann's message of "25 Aug 1998 13:49:42 +0200" Original-Lines: 53 X-Mailer: Gnus v5.6.37/XEmacs 20.4 - "Emerald" Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:16278 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:16278 >>>>> Kai Grossjohann : > 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