Re: Functional requirements for Gnus

["François Pinard" <pinard@iro.umontreal.ca>]

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