Re: Functional requirements for Gnus

[David Hedbor <david@hedbor.org>]

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.