* Functional requirements for Gnus @ 1998-08-26 14:15 Steinar Bang 1998-08-26 15:22 ` Simon Josefsson ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Steinar Bang @ 1998-08-26 14:15 UTC (permalink / raw) I've put my own initial requirements for the MIME support of pgnus into http://www.metis.no/private/sb/gnusmimereqs.html (never underestimate the usefulness of a plain text format) I'll fill the requirements of others posted to this list, as I find the time. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Functional requirements for Gnus 1998-08-26 14:15 Functional requirements for Gnus Steinar Bang @ 1998-08-26 15:22 ` Simon Josefsson 1998-08-26 15:29 ` Jean-Yves Perrier 1998-08-27 9:28 ` Steinar Bang 1998-08-28 9:29 ` Kai Grossjohann 2 siblings, 1 reply; 20+ messages in thread From: Simon Josefsson @ 1998-08-26 15:22 UTC (permalink / raw) Cc: ding Steinar Bang <sb@metis.no> writes: > I've put my own initial requirements for the MIME support of pgnus > into > http://www.metis.no/private/sb/gnusmimereqs.html > > (never underestimate the usefulness of a plain text format) > > I'll fill the requirements of others posted to this list, as I find > the time. I haven't seen it mentioned but I think mailcap/mimetype support is fundamental. TM only gave me headaches when I wanted to get fancy and configure it to my liking. Semignus shares my mailcap/mimetype with Netscape and things work smoothly. Semignus also does most of the things I've seen mentioned here. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Functional requirements for Gnus 1998-08-26 15:22 ` Simon Josefsson @ 1998-08-26 15:29 ` Jean-Yves Perrier 1998-08-26 16:05 ` Simon Josefsson 0 siblings, 1 reply; 20+ messages in thread From: Jean-Yves Perrier @ 1998-08-26 15:29 UTC (permalink / raw) Simon Josefsson <jas@pdc.kth.se> writes: > I haven't seen it mentioned but I think mailcap/mimetype support is > fundamental. Yes, but it should be overridable inside Gnus: that way I can have specific setting for Gnus only: the mailcap would be a default value. It would be nice if a mime types could trigger a lisp function -- Jean-Yves Perrier ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Functional requirements for Gnus 1998-08-26 15:29 ` Jean-Yves Perrier @ 1998-08-26 16:05 ` Simon Josefsson 1998-08-26 17:21 ` William M. Perry 0 siblings, 1 reply; 20+ messages in thread From: Simon Josefsson @ 1998-08-26 16:05 UTC (permalink / raw) Cc: ding Jean-Yves Perrier <perrier@nagra-kudelski.ch> writes: > > I haven't seen it mentioned but I think mailcap/mimetype support is > > fundamental. > > Yes, but it should be overridable inside Gnus: that way I can have > specific setting for Gnus only: the mailcap would be a default > value. The mailcap file format allows for client specific settings. image/gif: xv %s; \ x-gnus=mime-show-inline-gif; \ description="GIF Image" You could also have different Gnus settings for Emacs/XEmacs. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Functional requirements for Gnus 1998-08-26 16:05 ` Simon Josefsson @ 1998-08-26 17:21 ` William M. Perry 0 siblings, 0 replies; 20+ messages in thread From: William M. Perry @ 1998-08-26 17:21 UTC (permalink / raw) Cc: Jean-Yves Perrier, ding Simon Josefsson <jas@pdc.kth.se> writes: > Jean-Yves Perrier <perrier@nagra-kudelski.ch> writes: > > > > I haven't seen it mentioned but I think mailcap/mimetype support is > > > fundamental. > > > > Yes, but it should be overridable inside Gnus: that way I can have > > specific setting for Gnus only: the mailcap would be a default > > value. > > The mailcap file format allows for client specific settings. > > image/gif: xv %s; \ > x-gnus=mime-show-inline-gif; \ > description="GIF Image" > > You could also have different Gnus settings for Emacs/XEmacs. Emacs/W3 already deals with all the parsing and crap for mailcap and mimetypes files, and allows you to specify lisp-viewers from within a mailcap file. Right now it uses 'is the first character of the viewer a quote' to determine if it should be treated as an internal function. I could change this to x-emacs-viewer or something like that pretty easily. The appropriate file in Emacs/W3 is mm.el - it can be drastically improved pretty easily, and it is already signed over to the FSF since 1996. :) -Bill P. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Functional requirements for Gnus 1998-08-26 14:15 Functional requirements for Gnus Steinar Bang 1998-08-26 15:22 ` Simon Josefsson @ 1998-08-27 9:28 ` Steinar Bang 1998-08-28 9:29 ` Kai Grossjohann 2 siblings, 0 replies; 20+ messages in thread From: Steinar Bang @ 1998-08-27 9:28 UTC (permalink / raw) >>>>> Steinar Bang <sb@metis.no>: > I've put my own initial requirements for the MIME support of pgnus > into > http://www.metis.no/private/sb/gnusmimereqs.html > (never underestimate the usefulness of a plain text format) > I'll fill the requirements of others posted to this list, as I find > the time. I've put in the requirements of others that came in yesterday and the day before that. I've tried reformulating some of the requirements into functional requirements of the form of "I would like". I've also tried combining requirements that are the same thing. But I have limited time to devote to this, so you'll have to be your own editors and mail me the changes you would like to have me do to your requirements. And also please point out how requirements that are actually the same could be combined, and their number limited. - Steinar ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Functional requirements for Gnus 1998-08-26 14:15 Functional requirements for Gnus Steinar Bang 1998-08-26 15:22 ` Simon Josefsson 1998-08-27 9:28 ` Steinar Bang @ 1998-08-28 9:29 ` Kai Grossjohann 1998-08-28 10:15 ` David Hedbor ` (4 more replies) 2 siblings, 5 replies; 20+ messages in thread From: Kai Grossjohann @ 1998-08-28 9:29 UTC (permalink / raw) Cc: ding I've been thinking about the UI issues regarding this. I find that there are at least three different ways of presenting MIME messages to the user (especially multipart messages). I'm giving them titles to show where I got the inspiration. (1) `The TM alternative' The article buffer contains a button for each part. Textual parts also have the text included below the button. It is possible to move between the buttons. Each button can be pressed, causing the corresponding part to be displayed or saved on disk. There are two sub-alternatives: make one button per part and different keys for playing and saving (or, for down-mouse-2, a menu); or make two buttons per part, one for playing and one for saving. (2) `The digest alternative' Users can type C-d on a multipart message, causing it to be exploded as if it were a digest. In the resulting summary buffer, there are commands for viewing/playing each part (g or RET, I guess), and for saving each part. But how should the original article be displayed? One possibility would be to split the article window into two parts, one showing the nndoc digest summary and the other showing the message part currently selected. (The nndoc digest summary would be like a table of contents of the current article.) Another possibility would be to concatenate the textual parts, maybe interspersed with little markers showing where the non-textual MIME parts are. (3) `The X u alternative' For multipart messages, there is a command which creates pseudo-articles similar to the ones created by `X u' and friends. Either there's one pseudo-article per part and there are two commands, one for viewing/playing that part and another for saving it to disk, or there are two pseudo-articles per part, one for viewing/playing and one for saving. It is not yet clear to me how the original article should be displayed in this case. Maybe with the textual parts concatenated and little markers for the non-textual parts? I am not at all sure which alternative I would prefer. All of them have their merits. The advantage of (1) is that one gets a pretty good overview of the whole message contents, and it blends well with inline image displaying. The advantage of (2) is that there are lots of potentially useful things one could do in the nndoc summary buffer: save the part to a file (encoded or decoded), make a followup to that part only, copy that part into another group, ... Coming to think of it, I think I like (3) the least, but (1) and (2) are ties. Whatcha all think? kai -- OOP: object oriented programming; OOPS: object oriented mistakes ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Functional requirements for Gnus 1998-08-28 9:29 ` Kai Grossjohann @ 1998-08-28 10:15 ` David Hedbor 1998-08-28 11:22 ` Robert Bihlmeyer ` (3 subsequent siblings) 4 siblings, 0 replies; 20+ messages in thread From: David Hedbor @ 1998-08-28 10:15 UTC (permalink / raw) Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes: > > (1) `The TM alternative' [ snip ] > (2) `The digest alternative' [ snip ] > (3) `The X u alternative' [ snip ] > Coming to think of it, I think I like (3) the least, but (1) and (2) > are ties. 1 is definitely the one I would thing about first, but after reading this I think that 2 is the best. My reasons are first what you said - easy, well known, handling of the parts (just like normal messages). You can delete them, move them, save them or whatever individually. Another benefit with #2 compared to to TM system, is that with TM-style viewing, if you get a mail with 10 images (which happens to me now and then), displaying the message is very slow and use a lot of resources. Viewing one image at a time, in a "attachment buffer" would be much nicer. Perhaps a combination of 1 and 2 would be the best. Viewing could be something like this: Normal: headers First part, if it's text. [ tm-style button 1 ] (left mouser -> view, right -> menu with view, save etc) [ tm-style button 2 ] [ tm-text inserted ] Bla bla bla Whether or not the text should be inserted could be configured with a variable (max-text-length, -1 = unlimited, nil or 0 = not auto-inserted). When you press C-d you get the new buffer with all the parts. I don't know ELISP very well, but it shouldn't be too much harder to add that TM stuff compared to just listing the entries, or? In any case, a combination would be nice, but if I had to "choose", I'd prefer the second alternative. I don't really like the third at all. One thing that would be nice is if the size of each attachment was listed in the "default page". -- [ Below is a random fortune, which is unrelated to the above message. ] No line available at 300 baud. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Functional requirements for Gnus 1998-08-28 9:29 ` Kai Grossjohann 1998-08-28 10:15 ` David Hedbor @ 1998-08-28 11:22 ` Robert Bihlmeyer 1998-08-28 12:07 ` Kai Grossjohann 1998-08-28 14:37 ` François Pinard ` (2 subsequent siblings) 4 siblings, 1 reply; 20+ messages in thread From: Robert Bihlmeyer @ 1998-08-28 11:22 UTC (permalink / raw) >>>>> On 28 Aug 1998 11:29:47 +0200 >>>>> Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> said: Kai> I find that there are at least three different ways of Kai> presenting MIME messages to the user (especially multipart Kai> messages). You seem to be mainly concerned with multipart/mixed. What about multipart/alternative? m/digest, m/parallel, m/related should probably be treated much like m/mixed. There are also multipart/signed, multipart/encrypted, which should be handed over to mailcrypt. Kai> (1) `The TM alternative' Kai> [...] Textual parts also have the text included below the Kai> button. [...] This can extend to graphical parts at least in XEmacs. Hell, videos even. Kai> (2) `The digest alternative' Autoexplosion should be possible, like the following: Kai> But how should the original article be displayed? One Kai> possibility would be to split the article window into two Kai> parts, one showing the nndoc digest summary and the other Kai> showing the message part currently selected. [...] Kai> Another possibility would be to Kai> concatenate the textual parts, maybe interspersed with Kai> little markers showing where the non-textual MIME parts are. The latter is like (1) really, isn't it. Kai> (3) `The X u alternative' I think this is like (2), only with the submessages in the summary buffer, rather than a separate buffer. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! <robbe@orcus.priv.at> <http://stud2.tuwien.ac.at/~e9426626/sig.html> ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Functional requirements for Gnus 1998-08-28 11:22 ` Robert Bihlmeyer @ 1998-08-28 12:07 ` Kai Grossjohann 0 siblings, 0 replies; 20+ messages in thread From: Kai Grossjohann @ 1998-08-28 12:07 UTC (permalink / raw) Cc: ding >>>>> Robert Bihlmeyer <e9426626@stud2.tuwien.ac.at> writes: > You seem to be mainly concerned with multipart/mixed. What about > multipart/alternative? m/digest, m/parallel, m/related should > probably be treated much like m/mixed. There are also > multipart/signed, multipart/encrypted, which should be handed over > to mailcrypt. I think it would still be convenient if one had a listing of all parts of a multipart/alternative, so that one can choose one part to one's liking. But a message which is multipart/alternative should by default be displayed in a user-customizable preferred format, the above listing of alternatives should be an option only. kai -- OOP: object oriented programming; OOPS: object oriented mistakes ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Functional requirements for Gnus 1998-08-28 9:29 ` Kai Grossjohann 1998-08-28 10:15 ` David Hedbor 1998-08-28 11:22 ` Robert Bihlmeyer @ 1998-08-28 14:37 ` François Pinard 1998-08-28 15:05 ` Kai Grossjohann 1998-08-28 16:13 ` Phil Humpherys 1998-08-31 8:49 ` Steinar Bang 4 siblings, 1 reply; 20+ messages in thread From: François Pinard @ 1998-08-28 14:37 UTC (permalink / raw) Cc: Steinar Bang, ding Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes: > (1) `The TM alternative' > (2) `The digest alternative' > (3) `The X u alternative' Nice summary, thanks! Before going on, let me compare (2) and (3) a bit more. The mechanics in (3) has the advantage of letting users have a default action associated with each recognised part, which the user could later easily trigger. One disadvantage is that the mechanics is not currently set for handling deep hierarchical structures as sometimes found in MIME messages, another disadvantage is that only one action is defaulted for each part, a last one is that it abuses temporary files. All these could be corrected, of course, but (2) easily beats (3) on these points, and rather elegantly. Deep MIME hierarchies could be presented by blending them with article threading, for which Gnus already has a lot of nice features. Considering that each part in (2) may already be turned into a complete and valid MIME message, we have a rich set of actions that Gnus offers for handling them. Finally, the `nndoc' mechanism in (2) is such that we can postpone the creation of temporary files as much as needed. For all these reasons, despite (2) and (3) could be made to reach similar goals, I would not consider (3) further. In my opinion, the choice between (1) and (2) also depends on what one intends to do with a MIME message. Briefly said, the possible actions may be regrouped into four categories. Note that MIME handling could be overall split into composition and reception, I'm only discussing reception issues here. The problem of reassembling split parts, which has its own difficulties, is not addressed either (yet `rmime.el' does it very nicely). (A) `Presentation' The usual, default action does with non-MIME messages is to present them in an Article buffer, and the presentation problem for MIME messages is to use paradigms closest to the "normal" Gnus operations. Presentation of MIME messages should be bound to the already existing mechanics for washing, hiding and highligting articles. Plain texts would require no transformation, reference to external bodies could be turned into clickable references in messages, enriched text could be highlighted appropriately, foreign charsets could be displayed using fonts already available within Emacs. MIME-specific headers would be hidden, and the details of the presentation could be decided by a mix of washing/hiding options, selectable by hooks most probably, as it is done for other washing capabilities. MIME boundaries between entities are very thick and paragraph oriented, while HTML may really be inlined within sentences, not even requiring line breaks. Despite this ugliness of MIME, and seen under the proper angle, MIME and HTML both aim unified presentation. My guess is that Gnus should try to somewhat hide the fatness of MIME instead of consecrating its heaviness, trying its best at making MIME looking as light as possible. For example, one hardly think that an HTML browser should give the opportunity of seeing an image, without seeing the whole page containing it, and I'm tempted to look at a MIME composite message the same way. For presentation, there is not much choice, and (1) `The TM alternative' is the main way to go. However, you may consider that (2) `The digest alternative' is appealing for some big MIME messages, as we would rather like to concentrate on a hierarchical subset of it, like applying a lense for close-up. In a complex hierarchy of entities (not seen often yet, but it happens sometimes, and might happen more frequently as the community will continue learning how to use MIME), there is a need for looking at some intermediary part of a MIME tree, that is, more cleverly that strictly at the root or at a leaf. Presenting a node of a tree of MIME entities also implies the presentation of all sub-nodes of that node. `nndoc' already does this correctly. Yet, even if (2) allows users to select the viewpoint of their choice, it remains that (1) has to be used for presentation. (B) `Performance' The difference between presentation and performance is the dynamical aspect, as a sound cannot be "displayed" statically, and a movie could not usually be in Emacses. If a message contains "And I replied: [sound saying `Hello']", it would make sense thinking of the sound as static only if we had means to measure the eye movements of the users, and have `Hello' heard each time the eyes traverse the colon in the said (sic :-) quote. This cannot be easily be done, it is better to consider performance as separate from presentation. Of course, one might try hard to spare the necessity of separate performance. For example, one might use the cursor for approximating the eye, and merely moving the cursor could trigger presentation of dynamic elements. But to be honest, I'm not sure how appropriate this would be. If we cannot think of something really reasonable, and I'm not sure we can, it would be best to accept once and for all that merging presentation and performance should just not be attempted. Of course, this does not prevent users to hope being able to trigger performance from within the presentation, but these issues are separate. (C) `Extraction' Roughly said, extracting/saving a whole MIME message already works in Gnus, as a MIME message is also a generic message, which Gnus know how to handle. Extracting and low-level examination -- point (D) -- in MIME contexts, have this in common that they want to break down a MIME structure into separate entities that could be handled separately. Extracting and low-level examination (below), in MIME contexts, have this in common that they want to break down a MIME structure into separate entities that could be handled separately. I do not deny that the extraction need exists, but I would like to stress a bit that too often, the need is a consequence of the weakness of the presentation or performance tools. For example, one hardly think that an HTML browser should give the opportunity of seeing an image, without seeing the whole page containing it, and I'm tempted to look at a MIME composite message the same way. All this to say that extraction of MIME parts is somewhat unrelated to presentation. Once again, nothing prevents extraction to be triggered from within presentation, like in (1) `The TM alternative', but this time, it would be better be done from (2) `The digest alternative'. I mean that the real proper way is (2) for selecting a leaf to operate upon, but this does not prevent (1) from offering convenient short-cuts. (D) `Examination' Message examination is needed rarely, for those wanting to see the intimate structure of a somewhat unprocessed message, for debugging or understanding, or other low-level operations. Gnus already have tools for looking at a raw message, and my guess is that those tools are all sufficient already for MIME messages. The only problem might be to concentrate the examination on a specific MIME part, and (2) `The digest alternative' offers what is needed to select a viewpoint in the MIME tree. It would be overkill and a bit pollution to bring such considerations into (1) `The TM alternative'. David Hedbor <david@hedbor.org> writes: > Another benefit with #2 compared to to TM system, is that with TM-style > viewing, if you get a mail with 10 images (which happens to me now and > then), displaying the message is very slow and use a lot of resources. > Viewing one image at a time, in a "attachment buffer" would be much nicer. > [...] Whether or not the text should be inserted could be configured > with a variable [...] Of course, (1) `The TM alternative' should be hookable and parameterisable at will, and part of the implementation difficulty is be to reach a meaningful set of options that would make most people happy. The default behaviour of Gnus, given a MIME message, should become highly tunable in the long run. Robert Bihlmeyer <e9426626@stud2.tuwien.ac.at> writes: > You seem to be mainly concerned with multipart/mixed. What about > multipart/alternative? m/digest, m/parallel, m/related should probably > be treated much like m/mixed. There are also multipart/signed, > multipart/encrypted, which should be handed over to mailcrypt. Things become a bit simpler when one identifies the user intent, as processing choices might differ. To summarise the above: > (1) `The TM alternative' > (2) `The digest alternative' > (3) `The X u alternative' > (A) `Presentation' > (B) `Performance' > (C) `Extraction' > (D) `Examination' If we consider multipart/alternative, for example, it looks clear than (A) and (B) requires an alternative to be automatically taken, or else, looking at MIME messages would be unduly cumbersome. But for (C) and (D), this is quite different: all alternative parts should be explicitely available. Since (2) gives a finer (and fine :-) control on selection, it would be helpful when in an alternative situation even for (A) and (B). On the other hand, we should not loose sight that multipart/alternative could open the door to fairly complex structures each, not even similar. It would not be appropriate to mix selection menus within (1), or if we ever try to do so, we might be preparing for some miserable situations at some later time. To summarise this longish message, I merely think that our best bet has to be a mix of (1) `The TM alternative' and (2) `The digest alternative'. -- François Pinard mailto:pinard@iro.umontreal.ca Join the free Translation Project! http://www.iro.umontreal.ca/~pinard ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Functional requirements for Gnus 1998-08-28 14:37 ` François Pinard @ 1998-08-28 15:05 ` Kai Grossjohann 1998-08-28 16:04 ` François Pinard 0 siblings, 1 reply; 20+ messages in thread From: Kai Grossjohann @ 1998-08-28 15:05 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset=US-ASCII, Size: 1790 bytes --] You are saying that we would need to combine aspects of the TM-like operation and nndoc-like operation. Lemme think. 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. 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. The default rendering, then, can be specified by telling Gnus which [ ] to expand and which not to expand. 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. 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. 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? :-). Would that be the right mix, François? kai -- OOP: object oriented programming; OOPS: object oriented mistakes ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Functional requirements for Gnus 1998-08-28 15:05 ` Kai Grossjohann @ 1998-08-28 16:04 ` François Pinard 1998-08-28 16:26 ` Kai Grossjohann 1998-08-28 16:29 ` Kai Grossjohann 0 siblings, 2 replies; 20+ messages in thread From: François Pinard @ 1998-08-28 16:04 UTC (permalink / raw) Cc: ding Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> é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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Functional requirements for Gnus 1998-08-28 16:04 ` François Pinard @ 1998-08-28 16:26 ` Kai Grossjohann 1998-08-29 11:18 ` Lars Magne Ingebrigtsen 1998-08-28 16:29 ` Kai Grossjohann 1 sibling, 1 reply; 20+ messages in thread From: Kai Grossjohann @ 1998-08-28 16:26 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset=US-ASCII, Size: 1009 bytes --] >>>>> On 28 Aug 1998, François Pinard said: Kai> ,----- Kai> | * Root node Kai> | [+] Part 1 of a multipart/mixed Kai> | ( ) HTML version (multipart/alternative) Kai> | (*) ASCII version Kai> | bla bla bla bla bla... Kai> | [-] Part 2 of multipart/mixed is a GIF (not displayed) Kai> | [+] Part 3 of multipart/mixed Kai> `----- François> I'm not sure we really need that level of control before François> presentation, yet I presume we might discuss more cases to François> get a better idea. I did not mean `before presentation'. I meant that you get three windows for MIME messages: the summary buffer, the toc buffer, and the article buffer. The TOC buffer contains the information shown above. Which buttons (`[ ]' and `( )') are selected initially is determined from the default settings. Clicking one of buttons immediately affects what is shown in the article buffer. kai -- OOP: object oriented programming; OOPS: object oriented mistakes ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Functional requirements for Gnus 1998-08-28 16:26 ` Kai Grossjohann @ 1998-08-29 11:18 ` Lars Magne Ingebrigtsen 1998-08-31 13:03 ` Kai Grossjohann 0 siblings, 1 reply; 20+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-08-29 11:18 UTC (permalink / raw) Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes: > I did not mean `before presentation'. I meant that you get three > windows for MIME messages: the summary buffer, the toc buffer, and the > article buffer. The TOC buffer contains the information shown above. I think adding a third buffer might be a bit awkward -- if the user wants that fine-grained traversal of the MIME article, then the nndoc alternative would be the one to use. (`C-d' some multipart articles and have a peek at how it looks. I find that very useful when applying patches encoded in multipart messages, for instance.) -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Functional requirements for Gnus 1998-08-29 11:18 ` Lars Magne Ingebrigtsen @ 1998-08-31 13:03 ` Kai Grossjohann 1998-08-31 14:01 ` François Pinard 0 siblings, 1 reply; 20+ messages in thread From: Kai Grossjohann @ 1998-08-31 13:03 UTC (permalink / raw) >>>>> On 29 Aug 1998, Lars Magne Ingebrigtsen said: Lars> I think adding a third buffer might be a bit awkward -- if the Lars> user wants that fine-grained traversal of the MIME article, Lars> then the nndoc alternative would be the one to use. I've already seen the new nndoc MIME digest thing, very, very nifty! So if I understand you correctly, you are suggesting that there be one `concatenate everything' view of an article, and that there be the additional nndoc alternative, for viewing the `toc'. If there are nested body parts (a multipart/alternative as the second part of a multipart/mixed, say), would one then be able to create two nested nndoc groups? That'd be nice. I think the alternative outlined above is nice. I just wanted to make clear that there are other alternatives, maybe with their own merits. kai -- OOP: object oriented programming; OOPS: object oriented mistakes ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Functional requirements for Gnus 1998-08-31 13:03 ` Kai Grossjohann @ 1998-08-31 14:01 ` François Pinard 0 siblings, 0 replies; 20+ messages in thread From: François Pinard @ 1998-08-31 14:01 UTC (permalink / raw) Cc: ding Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes: > So if I understand you correctly, you are suggesting that there be one > `concatenate everything' view of an article, and that there be the > additional nndoc alternative, for viewing the `toc'. If there are > nested body parts (a multipart/alternative as the second part of a > multipart/mixed, say), would one then be able to create two nested > nndoc groups? That'd be nice. If there are nested parts (within parts), `nndoc' already gives you the full structure legibly, using proper indentation, and you can proceed with it without difficulty. Creating a nested separate `nndoc' group for one subset of a MIME message also works. Just type `C-d' another time for a sub-multipart in the `nndoc' group. It's surely fun to try, but my own feeling is that it is not very useful to do, as the first `nndoc' already has everything you need. If you nest many `nndoc' that way, you might have to type `q` a few times to pop out until the main summary reappears. -- François Pinard mailto:pinard@iro.umontreal.ca Join the free Translation Project! http://www.iro.umontreal.ca/~pinard ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Functional requirements for Gnus 1998-08-28 16:04 ` François Pinard 1998-08-28 16:26 ` Kai Grossjohann @ 1998-08-28 16:29 ` Kai Grossjohann 1 sibling, 0 replies; 20+ messages in thread From: Kai Grossjohann @ 1998-08-28 16:29 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset=US-ASCII, Size: 864 bytes --] >>>>> On 28 Aug 1998, François Pinard said: Kai> There should be additional commands for viewing this part in a Kai> separate buffer/window/frame, and there should be commands for Kai> saving it in files. François> Only if we already have the capability of viewing non-MIME François> messages into separate buffer/window/frame. MIME should François> not be too special. It should be blended within Gnus, not François> being something extraordinary, nor asking for too unusual François> devices. You've got a point there. Revised suggestion: There should be a command which toggles between: - restricting the article buffer to the currently selected part, and - showing the whole message. (By currently selected I mean the TOC display -- this tree-like thing.) kai -- OOP: object oriented programming; OOPS: object oriented mistakes ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Functional requirements for Gnus 1998-08-28 9:29 ` Kai Grossjohann ` (2 preceding siblings ...) 1998-08-28 14:37 ` François Pinard @ 1998-08-28 16:13 ` Phil Humpherys 1998-08-31 8:49 ` Steinar Bang 4 siblings, 0 replies; 20+ messages in thread From: Phil Humpherys @ 1998-08-28 16:13 UTC (permalink / raw) Cc: Steinar Bang, ding Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes: > (2) `The digest alternative' > > Users can type C-d on a multipart message, causing it to be > exploded as if it were a digest. In the resulting summary buffer, > there are commands for viewing/playing each part (g or RET, I > guess), and for saving each part. This one gets my vote. -- Phil Humpherys <phumpherys@utah-inter.net> DriverSoft Unix Systems Administrator Mobile: +1.801.725.3257 WWW/PGPkeys: http://www.spire.com/~humphery ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Functional requirements for Gnus 1998-08-28 9:29 ` Kai Grossjohann ` (3 preceding siblings ...) 1998-08-28 16:13 ` Phil Humpherys @ 1998-08-31 8:49 ` Steinar Bang 4 siblings, 0 replies; 20+ messages in thread From: Steinar Bang @ 1998-08-31 8:49 UTC (permalink / raw) >>>>> Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de>: > Coming to think of it, I think I like (3) the least, but (1) and (2) > are ties. > Whatcha all think? My preference is (1), mostly because that was what I had imagined a MIMEd mail would look like when I first read the MIME RFCs in the summer of 1993. (3) is pretty much what Mew did, and I didn't like it. I went back to MH-E+TM. But it would have its merits for stuff like digests. (2) I've never thought about before. I have to think about that. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~1998-08-31 14:01 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-08-26 14:15 Functional requirements for Gnus Steinar Bang 1998-08-26 15:22 ` Simon Josefsson 1998-08-26 15:29 ` Jean-Yves Perrier 1998-08-26 16:05 ` Simon Josefsson 1998-08-26 17:21 ` William M. Perry 1998-08-27 9:28 ` Steinar Bang 1998-08-28 9:29 ` Kai Grossjohann 1998-08-28 10:15 ` David Hedbor 1998-08-28 11:22 ` Robert Bihlmeyer 1998-08-28 12:07 ` Kai Grossjohann 1998-08-28 14:37 ` François Pinard 1998-08-28 15:05 ` Kai Grossjohann 1998-08-28 16:04 ` François Pinard 1998-08-28 16:26 ` Kai Grossjohann 1998-08-29 11:18 ` Lars Magne Ingebrigtsen 1998-08-31 13:03 ` Kai Grossjohann 1998-08-31 14:01 ` François Pinard 1998-08-28 16:29 ` Kai Grossjohann 1998-08-28 16:13 ` Phil Humpherys 1998-08-31 8:49 ` Steinar Bang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).