Re: Functional requirements for Gnus

[Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de>]

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