From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/16376 Path: main.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Fran=E7ois_Pinard?= Newsgroups: gmane.emacs.gnus.general Subject: Re: Functional requirements for Gnus Date: 28 Aug 1998 12:04:56 -0400 Sender: owner-ding@hpc.uh.edu Message-ID: References: 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 1035155259 27417 80.91.224.250 (20 Oct 2002 23:07:39 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 23:07:39 +0000 (UTC) Cc: ding@gnus.org 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 MAA09228 for ; Fri, 28 Aug 1998 12:14:31 -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 KAF09359; Fri, 28 Aug 1998 10:45:14 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 28 Aug 1998 11:13:52 -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 LAA26675 for ; Fri, 28 Aug 1998 11:13:35 -0500 (CDT) Original-Received: from pluton.rtsq.qc.ca (pluton.grics.qc.ca [199.84.132.10]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id MAA09213 for ; Fri, 28 Aug 1998 12:13:21 -0400 (EDT) Original-Received: by pluton.rtsq.qc.ca (8.8.8/8.8.8) with UUCP id MAA15931; Fri, 28 Aug 1998 12:05:39 -0400 Original-Received: by icule.progiciels-bpi.ca (8.8.5/8.7.3) id MAA01598; Fri, 28 Aug 1998 12:04:57 -0400 Original-To: Kai Grossjohann X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m écrit: > What I like about the nndoc solution is that there is a rather nice > `table of contents' of the MIME message. OT1H, I think I wouldn't want > to miss that. OTOH, often one wants to read the whole message in sequence. Hello, Kai. Of course, you guessed I have some of a sort of overall picture in my head about how it could work :-). For the "OTOH", one might like to have either a global rendering of the MIME article in a single article buffer, or traverse the tree one leaf at a time, having a rendered view of that leaf. Or a mix of both approaches maybe. The global rendering should be achieved by selecting, in the summary, any multipart MIME message. The step-wise rendering could be achieved by having some new kind of "n"ext command in an `nndoc' summary, able to cleverly skip over multipart lines as they are not leaves, and even able to automatically pick in an alternative. (In fact, the defaults for this special "n" might be identical to the defaults for global rendering.) > This would lead to a tree-like view of the message: > ,----- > | * Root node > | [+] Part 1 of a multipart/mixed > | ( ) HTML version (multipart/alternative) > | (*) ASCII version > | bla bla bla bla bla... > | [-] Part 2 of multipart/mixed is a GIF (not displayed) > | [+] Part 3 of multipart/mixed > `----- > I think this tree should be rendered somehow. Then, we would specify > for each of the [ ] and ( ) items which of them should be shown and > which wouldn't. The ( ) would behave like radio buttons -- only one > of them can be active at any time. The [ ] could each be expanded, at > will. I'm not sure we really need that level of control before presentation, yet I presume we might discuss more cases to get a better idea. In the above, the user might have decided in advance that s/he wants (or not) GIFs inlined by default, and s/he could explicitely hit `SPC' (or not) over GIF parts to see them, in so overriding the default. The same would apply to selection of ASCII over HTML or vice-versa. Of course, the idea above is surely nice, but I do not think it is essential. We might better aim for simplicity, as far as possible, and not add too many features which are not truly needed. > Hm. For each item in the table of contents, selecting it would jump in > the article buffer to the right place, except for items which can't be > displayed inline -- there, it would start the appropriate external viewer. Options could allow users to perform (automatically or with confirmation) single-part messages which would not be meaningful to present. So, the usual selection (with `SPC') of articles would do from the `nndoc' summary. > There should be additional commands for viewing this part in a separate > buffer/window/frame, and there should be commands for saving it in files. Only if we already have the capability of viewing non-MIME messages into separate buffer/window/frame. MIME should not be too special. It should be blended within Gnus, not being something extraordinary, nor asking for too unusual devices. > In addition to the TOC, there should be little visual markers in the > article buffer -- similar to a section heading in ordinary structured > texts. These marks would be buttons for launching external programs > for the non-inline items (out-of-line items? :-). The same as we may have buttons for hidden citations, and such other things. In fact, the (1) option should merely be additions to the usual rendering of articles. Maybe a bit more complex to program and implement internally, but nothing very new nor very special for Gnus users. -- François Pinard mailto:pinard@iro.umontreal.ca Join the free Translation Project! http://www.iro.umontreal.ca/~pinard