Functional requirements for Gnus

Functional requirements for Gnus

[Steinar Bang]

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.

Re: Functional requirements for Gnus

[Simon Josefsson]

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.

Re: Functional requirements for Gnus

[Jean-Yves Perrier]

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

Re: Functional requirements for Gnus

[Simon Josefsson]

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.

Re: Functional requirements for Gnus

[William M. Perry]

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.

Re: Functional requirements for Gnus

[Steinar Bang]

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

Re: Functional requirements for Gnus

[Kai Grossjohann]

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

Re: Functional requirements for Gnus

[David Hedbor]

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.

Re: Functional requirements for Gnus

[Robert Bihlmeyer]

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

Re: Functional requirements for Gnus

[Kai Grossjohann]

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

Re: Functional requirements for Gnus

[François Pinard]

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

Re: Functional requirements for Gnus

[Kai Grossjohann]

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

Re: Functional requirements for Gnus

[François Pinard]

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

Re: Functional requirements for Gnus

[Kai Grossjohann]

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

Re: Functional requirements for Gnus

[Lars Magne Ingebrigtsen]

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

Re: Functional requirements for Gnus

[Kai Grossjohann]

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

Re: Functional requirements for Gnus

[François Pinard]

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

Re: Functional requirements for Gnus

[Kai Grossjohann]

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

Re: Functional requirements for Gnus

[Phil Humpherys]

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

Re: Functional requirements for Gnus

[Steinar Bang]

>>>>> 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.