From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/16909 Path: main.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.gnus.general Subject: Those MIME requirements Date: 11 Sep 1998 13:35:16 +0200 Sender: owner-ding@hpc.uh.edu Message-ID: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1035155704 30604 80.91.224.250 (20 Oct 2002 23:15:04 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 23:15:04 +0000 (UTC) Return-Path: Original-Received: from gizmo.hpc.uh.edu (gizmo.hpc.uh.edu [129.7.102.31]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id HAA11926 for ; Fri, 11 Sep 1998 07:35:47 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (sina.hpc.uh.edu [129.7.3.5]) by gizmo.hpc.uh.edu (8.7.6/8.7.3) with ESMTP id GAF10300; Fri, 11 Sep 1998 06:06:49 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 11 Sep 1998 06:33:56 -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 GAA00507 for ; Fri, 11 Sep 1998 06:33:44 -0500 (CDT) Original-Received: from sparky.gnus.org (ppp028.uio.no [129.240.240.29]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id HAA11902 for ; Fri, 11 Sep 1998 07:33:29 -0400 (EDT) Original-Received: (from larsi@localhost) by sparky.gnus.org (8.8.5/8.8.5) id NAA03046; Fri, 11 Sep 1998 13:36:31 +0200 X-Now-Reading: Madeleine L'Engle's _A Wrinkle in Time_ Original-To: ding@gnus.org User-Agent: Gnus/5.070027 (Pterodactyl Gnus v0.27) XEmacs/21.0 (Finnish Landrace) X-Face: &w!^oO~dS|}-P0~ge{$c!h\>From Steinar's (ouch. it hurts to use an apostrophe before the posessive "s" after Norwegian names) list of MIME requirements. (I've skipped the composition reqs.) > ****** > REQ-1 - automatic decoding of text > I would like automatic decoding of q-b or base64 encoded text/plain > message parts > (19980825 Steinar Bang ) Check. > ****** > REQ-2 - inline image attachments > I would like to view images (JPEG, GIF, PNG) inline in the message > (19980825 Steinar Bang ) Check. > ****** > REQ-3 - saving image attachments > I would like a simple way to save image attachments > (19980825 Steinar Bang ) Check. > ****** > REQ-4 - navigation in multipart/mixed messages > I would like a simple way of navigating through a multipart > message, and view and save the parts. I rather like the current TM > behaviour for this > (19980825 Steinar Bang ) How does TM navigate through the multipart/mixed messages? > ****** > REQ-5 - display of text/html > 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 > (19980825 Steinar Bang ) Don't w3 have to display things in its own buffer? Anyway, 0.27 will display html with w3 in a separate buffer, which brings up the question: How is Gnus supposed to display things that are displayed by Emacs, but not in the article buffer? Gnus has to pop up a new buffer, but is that buffer supposed to replace the article buffer, or what? > ****** > REQ-6 - toggle between text/html and text/plain > I would like to be easily able to toggle between text/plain and > text/html parts of a multipart/alternative > (19980825 Steinar Bang ) Ooh. multipart/alternative. It's not handled exactly the same way as multipart/mixed, which is obviously not good, but I can't visualize how this is supposed to look with the current buttonized scheme. > ****** > REQ-7 - replying to text/html > 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) > (19980825 Steinar Bang ) And this goes for all things that Emacs display, but not in the article buffer (see REQ-5). Or? > ****** > REQ-8 - formatted MSWord documents shown inline > 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 > (19980825 Steinar Bang ) Sure. Send me rules to plonk into `mailcap-mime-data' (as default settings) for doing this and other wonderful things. (I mean -- displaying weird formats and stuff.) > ****** > REQ-9 - prompt for filename when saving attachments > I would like to be prompted for directory and filename, when saving > attachments > (19980825 Alan Shutko ) > (19980825 Jan Vroonhof ) Check. > ****** > REQ-10 - implement everything in elisp > I would like the MIME support in Gnus to be completely implemented in > elisp, and to rely on external programs only as a speedup option > (19980825 Jan Vroonhof ) Check. Well, it relies on C-layer support to speed things up. base64 de/encoding in C will be in Emacs 20.4, for instance. > ****** > REQ-11 - extract part to buffer > I would like to be able to extract a message part to an emacs buffer > (19980825 Jan Vroonhof ) Fix in Pterodactyl Gnus v0.27. > ****** > REQ-12 - use richest format by default > 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. > (19980825 François Pinard ) I've now added a `mm-alternative-precedence' variable that would determine which alternative part is to be displayed, but the way to display the "other" parts has to be worked out. > ****** > REQ-16 - display of message parts > 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). [VM behaviour] > (19980826 Kees de Bruin ) Check. > ****** > REQ-17 - saving message parts > 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. [VM behaviour] > (19980826 Kees de Bruin ) Check > ****** > REQ-18 - message parts converted into plain text > Alternative display of MIME messages: plain text (no conversions), using > inline display, or all buttons. [VM behaviour] > (19980826 Kees de Bruin ) Check. (I think.) > ****** > REQ-19 - handling of MIME digests > I would like Gnus to handle MIME digests [a closer description, maybe?] > (19980826 Kees de Bruin ) nndoc takes care of this. > ****** > REQ-20 - integration of MIME support with nnimap > 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) > (19980826 Steinar Bang ) That would be nice. > ****** > REQ-21 - handling of message-internal URIs > 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. > (19980826 Jean-Yves Perrier ) In what way are these used? > ****** > REQ-22 - a choice when handling attachments > I would like nice handling of file attachments. There should be a > choice whether you want to save the attachment (and it should query > for a file name), view the attachment in an Emacs buffer, or start > an external command on the attachment. > (19980826 Hrvoje Niksic ) Check. > ****** > REQ-23 - support for mailcap > I would like support for .mailcap. This is important, as well-configured > systems (such as Debian Linux releases) are actually using mailcaps to > specify external programs associated to various document formats. I > haven't looked at Bill's code, so I don't know how applicable it is. > (19980826 Hrvoje Niksic ) > I think mailcap/mimetype support is fundamental. > (19980826 Simon Josefsson ) Check. > ****** > REQ-24 - support for RFC2047 in headers > I would like support for decoding/encoding of RFC2047 headers. This is > partially connected with Mule, but not necessarily. > (19980826 Hrvoje Niksic ) Check. > ****** > REQ-27 - mailcap support for elisp > I would like mailcap files to be able to execute emacs lisp functions > on the contents of a message part. > (19980826 Jean-Yves Perrier ) application/emacs-lisp will eval Emacs Lisp functions. (After asking, of course.) Is that what you mean? -- (domestic pets only, the antidote for overdose, milk.) larsi@ifi.uio.no * Lars Magne Ingebrigtsen