Pterodactyl Gnus v0.46 is released

Pterodactyl Gnus v0.46 is released

[Lars Magne Ingebrigtsen]

Bugfix.

Get it from <URL:http://www.gnus.org/pgnus.tar.gz> or
"/ftp@ftp.gnus.org:/pub/emacs/gnus/".  The patch is available as
<URL:http://www.gnus.org/patches/pgnus-0.45-0.46.diff.gz>.

ChangeLog since last release:

Sun Nov 15 02:01:31 1998  Lars Magne Ingebrigtsen  <larsi@menja.ifi.uio.no>

	* gnus.el: Pterodactyl Gnus v0.46 is released.

1998-11-15 01:54:40  Lars Magne Ingebrigtsen  <larsi@gnus.org>

	* message.el (message-encode-message-body): Insert headers at the
	right spot.



-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Magne Ingebrigtsen

Re: Pterodactyl Gnus v0.46 is released

[Graham Murray]

A couple of observations. I don't know if 0.47 has cured these.

1) The Mime-Version header is repeated.
2) There seems to be a large number of blank lines between the header
and the start of the body.

Re: Pterodactyl Gnus v0.46 is released

[Graham Murray]

Graham Murray <graham@barnowl.demon.co.uk> writes:

> A couple of observations. I don't know if 0.47 has cured these.
> 
> 1) The Mime-Version header is repeated.
> 2) There seems to be a large number of blank lines between the header
> and the start of the body.

I posted too soon, 0.47 seems to have fixed these. - Sorry.

Re: Pterodactyl Gnus v0.46 is released

[Lars Magne Ingebrigtsen]

Graham Murray <graham@barnowl.demon.co.uk> writes:


> > 2) There seems to be a large number of blank lines between the header
> > and the start of the body.
> 
> I posted too soon, 0.47 seems to have fixed these. - Sorry.

There were still too many blank lines in 0.49, but I've now whittled
them down a bit.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Pterodactyl Gnus v0.46 is released

[Alexandre Oliva]

On Nov 17, 1998, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> Graham Murray <graham@barnowl.demon.co.uk> writes:

>> > 2) There seems to be a large number of blank lines between the header
>> > and the start of the body.
>> 
>> I posted too soon, 0.47 seems to have fixed these. - Sorry.

> There were still too many blank lines in 0.49, but I've now whittled
> them down a bit.

It would also be nice if gnus wouldn't spend two lines just to tell me
that the message contains a single plain-text part.  I'd prefer to
have the `[1. text]' line ommitted.

And how 'bout decoding the ugly `=?ISO...?=' encodings that appear in
headers of some messages, particularly ones posted with TM/SEMI?

Another interesting issue I noticed: can anyone think of a reason why
several MIME type options appear duplicated for me if I hit TAB when
gnus asks me for the `MIME type for /some/file'?  Some types appear up
to 6 times!  Not that it's wrong, it just seems strange...

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org.au}
Universidade Estadual de Campinas, SP, Brasil

Re: Pterodactyl Gnus v0.46 is released

[Lars Magne Ingebrigtsen]

Alexandre Oliva <oliva@dcc.unicamp.br> writes:


> It would also be nice if gnus wouldn't spend two lines just to tell me
> that the message contains a single plain-text part.  I'd prefer to
> have the `[1. text]' line ommitted.

You only get buttons in multipart messages.  Is it common to send
multipart messages that only contain a single part?  Why would people
do that?  (Except me, of course, over the past few days.  :-)

> And how 'bout decoding the ugly `=?ISO...?=' encodings that appear in
> headers of some messages, particularly ones posted with TM/SEMI?

I haven't seen any Q encodings of headers in eons.  Could you give us
an example?

> Another interesting issue I noticed: can anyone think of a reason why
> several MIME type options appear duplicated for me if I hit TAB when
> gnus asks me for the `MIME type for /some/file'?  Some types appear up
> to 6 times!  Not that it's wrong, it just seems strange...

Gnus should probably whittle those down a bit; yes...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Pterodactyl Gnus v0.46 is released

[Alexandre Oliva]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]


On Nov 18, 1998, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> Alexandre Oliva <oliva@dcc.unicamp.br> writes:


>> It would also be nice if gnus wouldn't spend two lines just to tell me
>> that the message contains a single plain-text part.  I'd prefer to
>> have the `[1. text]' line ommitted.

> You only get buttons in multipart messages.  Is it common to send
> multipart messages that only contain a single part?  Why would people
> do that?  (Except me, of course, over the past few days.  :-)

We're on the same boat :-)

I'm not sure this is common, but we could make it a special case if
gnus will keep posting such messages.  I don't think there's any
reason not to post them like this...

>> And how 'bout decoding the ugly `=?ISO...?=' encodings that appear in
>> headers of some messages, particularly ones posted with TM/SEMI?

> I haven't seen any Q encodings of headers in eons.  Could you give us
> an example?

I'd like to have attached a message containing such encodings, but I
couldn't find any way to do it.  

Here's a file containing such a message, anyway...

[-- Attachment #2: Type: application/octet-stream, Size: 4762 bytes --]

X-From-Line: tm-en-return-1912-oliva=dcc.unicamp.br@chamonix.jaist.ac.jp Mon Nov 16 05:21 EDT 1998
Received: from grande.dcc.unicamp.br (grande.dcc.unicamp.br [143.106.7.8])
	by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id FAA02527
	for <oliva@amazonas.dcc.unicamp.br>; Mon, 16 Nov 1998 05:21:54 -0200 (EDT)
Received: from chamonix.jaist.ac.jp (chamonix.jaist.ac.jp [150.65.194.23])
	by grande.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id FAA03783
	for <oliva@dcc.unicamp.br>; Mon, 16 Nov 1998 05:21:30 -0200 (EDT)
Received: (qmail 11701 invoked by uid 6); 16 Nov 1998 16:23:28 +0900
Received: (qmail 11695 invoked from network); 16 Nov 1998 16:23:27 +0900
Received: from mail.jaist.ac.jp (150.65.38.20)
  by chamonix.jaist.ac.jp with ESMTP; 16 Nov 1998 16:23:26 +0900
Received: from mousai.jaist.ac.jp (mousai [150.65.41.143]) by mail.jaist.ac.jp (3.7W-jaist_mail) with ESMTP id QAA29852; Mon, 16 Nov 1998 16:23:25 +0900 (JST)
Mailing-List: contact tm-en-help@chamonix.jaist.ac.jp; run by ezmlm-idx
X-Ml-Name: tm(en) / tm ML (English Version)
Precedence: bulk
Delivered-To: mailing list tm-en@chamonix.jaist.ac.jp
X-Ml-Count: 1912
Sender: morioka@mousai.jaist.ac.jp
To: tm-en@chamonix.jaist.ac.jp
Subject: SEMI 1.11.0 (Kanazawa)
Organization: Japan Advanced Institute of Science and Technology, Hokuriku
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= (MORIOKA Tomohiko)
 <morioka@jaist.ac.jp>
MIME-Version: 1.0 (generated by SEMI 1.11.0 - "Kanazawa")
Content-Transfer-Encoding: 7bit
Date: 16 Nov 1998 16:23:26 +0900
Message-ID: <s1clnlcm781.fsf@mousai.jaist.ac.jp>
User-Agent: Chao-gnus/6.12.4 SEMI/1.11.0 (Kanazawa) FLIM/1.12.0 (Amagatsuji) MULE XEmacs/21.0 (Norwegian) (i586-pc-linux)
Content-Type: multipart/mixed;
 boundary="Multipart_Mon_Nov_16_16:23:25_1998-2"
X-Content-Length: 2911
Lines: 105
Xref: araguaia.dcc.unicamp.br tm:62

--Multipart_Mon_Nov_16_16:23:25_1998-2
Content-Type: text/plain; charset=US-ASCII

[Status] beta


[Required Environment]

APEL: 9.11 or later
FLIM: 1.12.0 or later


[Changes]

1998-11-16  MORIOKA Tomohiko  <morioka@jaist.ac.jp>

	* SEMI: Version 1.11.0 (Kanazawa) released.

	* README.ja, README.en (Required environment): Modify for APEL
	9.11 and FLIM 1.12.0.

1998-11-12  Katsumi Yamaoka   <yamaoka@jpl.org>

	* mime-edit.el (mime-edit-split-ignored-field-regexp): Add "^".

1998-11-08  MORIOKA Tomohiko  <morioka@jaist.ac.jp>

	* mime-bbdb.el (mime-bbdb/update-record): Use
	`mime-decode-field-body' instead of
	`eword-decode-structured-field-body'.

1998-10-31  MORIOKA Tomohiko  <morioka@jaist.ac.jp>

	* mime-edit.el (mime-edit-decode-message-in-buffer): Delete fields
	match with `mime-edit-again-ignored-field-regexp' then call
	`mime-decode-header-in-buffer'.
	(mime-edit-again): Delete header filter.

1998-10-31  MORIOKA Tomohiko  <morioka@jaist.ac.jp>

	* mime-edit.el (mime-edit-decode-multipart-in-buffer): Change
	interface.
	(mime-edit-decode-single-part-in-buffer): New function.
	(mime-edit-decode-message-in-buffer): Swap arguments; use function
	`mime-edit-decode-single-part-in-buffer'.
	(mime-edit-again): Modify for
	`mime-edit-decode-message-in-buffer'.

1998-10-31  MORIOKA Tomohiko  <morioka@jaist.ac.jp>

	* mime-edit.el (mime-edit-decode-multipart-in-buffer): New
	function.
	(mime-edit-decode-message-in-buffer): Add new optional argument
	`default-content-type'; use function
	`mime-edit-decode-multipart-in-buffer'; add autoload cookie.
	(mime-edit-again): Add autoload cookie.

	* mime-edit.el (mime-edit-decode-message-in-buffer): Renamed from
	`mime-edit-decode-buffer'; change `not-decode-text' to optional
	argument.


--Multipart_Mon_Nov_16_16:23:25_1998-2
Content-Type: multipart/alternative;
 boundary="Multipart_Mon_Nov_16_16:23:25_1998-1"
Content-Transfer-Encoding: 7bit

--Multipart_Mon_Nov_16_16:23:25_1998-1
Content-Type: text/plain; charset=US-ASCII


  It is available from

    ftp://ftp.jaist.ac.jp/pub/GNU/elisp/semi/


--Multipart_Mon_Nov_16_16:23:25_1998-1
Content-Type: message/external-body;
	access-type=anon-ftp;
	site="ftp.jaist.ac.jp";
	directory="/pub/GNU/elisp/semi";
	name="semi-1.11.0.tar.gz";
	mode=image

Content-Type: application/octet-stream;
	name="semi-1.11.0.tar.gz";
	type=tar;
	conversions=gzip

--Multipart_Mon_Nov_16_16:23:25_1998-1--

--Multipart_Mon_Nov_16_16:23:25_1998-2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

-- =

----------------------------------------------------------------------
MORIOKA Tomohiko <morioka@jaist.ac.jp>
        Japan advanced Institute of Science and Technology, Hokuriku
                Asahi-dai, Tatsu-no-kuchi ch=F4, Nomi, Ishikawa, Japan
------------------------------------------ Frisch, Frei, Fr=F6hlich! ---

--Multipart_Mon_Nov_16_16:23:25_1998-2--


[-- Attachment #3: Type: text/plain, Size: 180 bytes --]




-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org.au}
Universidade Estadual de Campinas, SP, Brasil

Re: Pterodactyl Gnus v0.46 is released

[Lars Magne Ingebrigtsen]

Alexandre Oliva <oliva@dcc.unicamp.br> writes:


> I'm not sure this is common, but we could make it a special case if
> gnus will keep posting such messages.  I don't think there's any
> reason not to post them like this...

Multiparts are ugly.  There's no reason to post multiparts unless one
has to.

> Here's a file containing such a message, anyway...

It decoded perfetcly for me.  What's your `gnus-article-decode-hook'? 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Pterodactyl Gnus v0.46 is released

[Alexandre Oliva]

On Nov 18, 1998, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

>> Here's a file containing such a message, anyway...

> It decoded perfetcly for me.

Good to know.

> What's your `gnus-article-decode-hook'? 

Value: (article-decode-charset article-decode-encoded-words)

Maybe it's just because I'm running the ``ancient'' pgnus 0.48, and
you're running 0.51... ;-)

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org.au}
Universidade Estadual de Campinas, SP, Brasil

Re: Pterodactyl Gnus v0.46 is released

[Lars Magne Ingebrigtsen]

Alexandre Oliva <oliva@dcc.unicamp.br> writes:


> > What's your `gnus-article-decode-hook'? 
> 
> Value: (article-decode-charset article-decode-encoded-words)

That's ok.

> Maybe it's just because I'm running the ``ancient'' pgnus 0.48, and
> you're running 0.51... ;-)

Get with the times!  Groove on up!  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Pterodactyl Gnus v0.46 is released

[Kai.Grossjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

  > You only get buttons in multipart messages.

No.  See the following message:

,-----
| X-From-Line: Kai.Grossjohann@CS.Uni-Dortmund.DE Wed Nov 18 09:19:55 1998
| Received: from amaunet.informatik.uni-dortmund.de (amaunet [129.217.20.113])
|         by marcy.informatik.uni-dortmund.de id JAA06980; Wed, 18 Nov 1998 09:19:54 +0100
| Received: from ramses.informatik.uni-dortmund.de (ramses [129.217.20.180])
|         by amaunet.informatik.uni-dortmund.de id JAA01053; Wed, 18 Nov 1998 09:19:53 +0100
| Received:  (grossjoh@localhost)
|         by ramses.informatik.uni-dortmund.de id JAA22322; Wed, 18 Nov 1998 09:19:52 +0100
| To: Kai Grossjohann <grossjohann@ls6.informatik.uni-dortmund.de>
| Subject: mime-test
| Mime-Version: 1.0
| Content-type: text/html
| Content-transfer-encoding: 8bit
| From: Kai.Grossjohann@CS.Uni-Dortmund.DE
| Date: 18 Nov 1998 09:19:50 +0100
| Message-ID: <vaf7lwt76qh.fsf@ramses.cs.uni-dortmund.de>
| User-Agent: Gnus/5.070048 (Pterodactyl Gnus v0.48) Emacs/20.3
| Mime-Version: 1.0
| X-Content-Length: 80
| Lines: 10
| Xref: ramses.cs.uni-dortmund.de inbox:42334
| 
| 
| 
| <html>
| This is <em>html</em>.
| 
| kai
| -- 
| Life is hard and then you die.
| </html>
| 
`-----

When displaying this message in 0.49, a [1. text/html] button is shown.

kai
-- 
Life is hard and then you die.

Re: Pterodactyl Gnus v0.46 is released

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:


>   > You only get buttons in multipart messages.
> 
> No.  See the following message:

Ah; yes -- only singlepart text/plain messages are buttonless.  Which
makes sense to me, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Pterodactyl Gnus v0.46 is released

[François Pinard]

Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Is it common to send multipart messages that only contain a single part?

Not really common, yet I remember having (softly :-) complained to a few
of my correspondents who were always doing that.

> Why would people do that?

Presumably because they do not have full control over their MUAs?

> > And how 'bout decoding the ugly `=?ISO...?=' encodings that appear in
> > headers of some messages, particularly ones posted with TM/SEMI?

> I haven't seen any Q encodings of headers in eons.  Could you give us
> an example?

Do you mean RFC1522 (now RFC2070, if not mistaken)?

Even if ugly, these address a real need.  Of course, you'll more likely
see B for messages showing Asian names, but for Latin languages sharing
many letters with the English alphabet, Q is still likely to occur.

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: Pterodactyl Gnus v0.46 is released

[Lars Magne Ingebrigtsen]

François Pinard <pinard@iro.umontreal.ca> writes:

> > Is it common to send multipart messages that only contain a single part?
> 
> Not really common, yet I remember having (softly :-) complained to a few
> of my correspondents who were always doing that.

Yup.

Anyway, perhaps we should just drop the buttons for all the text/plain 
parts totally?  It's not like anyone wants to toggle those parts...
although I guess people might want to save them separately and stuff.
Hm.

> > I haven't seen any Q encodings of headers in eons.  Could you give us
> > an example?
> 
> Do you mean RFC1522 (now RFC2070, if not mistaken)?
> 
> Even if ugly, these address a real need.  Of course, you'll more likely
> see B for messages showing Asian names, but for Latin languages sharing
> many letters with the English alphabet, Q is still likely to occur.

Yes, but I meant that I haven't seen them, since Gnus decodes them
automatically now.  :-)  (Both Q and B encodings.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Pterodactyl Gnus v0.46 is released

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Anyway, perhaps we should just drop the buttons for all the text/plain 
> parts totally?

Please don't drop the buttons.  Yes, I would like to toggle them -- if 
they are sent as multipart, I assume there must be a reason for that.
The separate saving is also an issue.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Latest O'Reilly edition:
  Database Management with POSTSCRIPT ("The Flying Fish Book")

Re: Pterodactyl Gnus v0.46 is released

[Lee Willis]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Please don't drop the buttons.  Yes, I would like to toggle them -- if 
> they are sent as multipart, I assume there must be a reason for that.
> The separate saving is also an issue.

Can we have it perhaps as an option as I don't want to toggle them and
therefore I'd prefer not to see them. Maybe
gnus-article-show-text-button ?

Lee.
-- 
I was doing object-oriented assembly at 1 year old ...  
For some reason my mom insists on calling it "Playing with blocks"

Re: Pterodactyl Gnus v0.46 is released

[Hrvoje Niksic]

Lee Willis <lee@gbdirect.co.uk> writes:

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > Please don't drop the buttons.  Yes, I would like to toggle them -- if 
> > they are sent as multipart, I assume there must be a reason for that.
> > The separate saving is also an issue.
> 
> Can we have it perhaps as an option as I don't want to toggle them
> and therefore I'd prefer not to see them. Maybe
> gnus-article-show-text-button ?

Or, even better, a more general way of telling Gnus which types you
want to have buttons for, and which types you don't.  Of course, there 
should also be a function to buttonize everything.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Q: What's an IBM man-year?
A: 730 people trying to get a project done before noon.

Re: Pterodactyl Gnus v0.46 is released

[François Pinard]

Lars Magne Ingebrigtsen <larsi@gnus.org> écrit:

> Anyway, perhaps we should just drop the buttons for all the text/plain
> parts totally?

Yes.  They are noisy, and not useful.

> It's not like anyone wants to toggle those parts...  although I guess
> people might want to save them separately and stuff.  Hm.

I really think we should try to see MIME and HTML as two different ways
(the old and the new) to produce _unified_ multimedia presentations.
In some case, extraction of parts is related to the presentation, like
for file transmission types, but in other cases, like text or image types,
they are not.

It would not come to mind to have heavy mechanics and buttons in an
HTML browser to extract substrings of the overall page.  The same spirit
should apply to MIME in Gnus.  It is only normal that one should resort
to special unusual devices to extract substrings, like calling for the
HTML sources and using an editor, or the overall cut-an-paste mechanics
of the window system.  In Gnus, if one wants to really fiddle with MIME
internals, one can use either `C-u g', possibly combined with `C-d', to
access internals, or intimate parts of a MIME message.

MIME usually have heavy user interface implementations.  Gnus could try
to do better, and have something lightier by default.  I would hope from a
good MUA that it hides MIME complexities from me, instead of revealing them,
the same as good HTML browsers do.  The constant goal might be that MIME is
not much heavier than HTML, everywhere it is reasonable that it stays light.

Handling textual parts separately, with buttons and such, is overkill in
the default presentation.  Moreover, I do not think it really fits the
original intent of MIME.  When it's more of an internal/binary/dissection
matter, then it should be kept out of the way.  `C-d' only exists as a
way to resolve in advance some accessory, less important needs, *so* that
a MIME-viewer could later be tackled with a more free design, not to be
uncumbered with things not really meant to be there.

I've not yet seen a MIME-viewer that reaches the unified presentation
intent of Nathaniel Boreinstein, yet it's true I'm far from having seen them
all :-).  I would surely like that Gnus avoids the usual mere-bag-of-tricks
approach to MIME, and rather become a real good MIME viewer.

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: Pterodactyl Gnus v0.46 is released

[Edward J. Sabol]

Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
LMI> Anyway, perhaps we should just drop the buttons for all the text/plain
LMI> parts totally?

Francois Pinard <pinard@IRO.UMontreal.CA> wrote:
FP> Yes.  They are noisy, and not useful.

I agree completely. (By the way, your argument against them was very well
presented.)

I think the only time there should be a button for a text/* part (not just
text/plain, but anything text) is if it's in a multipart/alternative
grouping.

Re: Pterodactyl Gnus v0.46 is released

[François Pinard]

"Edward J. Sabol" <sabol@alderaan.gsfc.nasa.gov> writes:

> I think the only time there should be a button for a text/* part (not
> just text/plain, but anything text) is if it's in a multipart/alternative
> grouping.

Even then, I would think that alternatives were mainly invented to cope
with situations where there are limitations in the presentation devices (no
sound, no bitmaps) and such things.  A bit like Lynx which is able to use
an alternative label to an image, which label is part of the HTML image tag,
and which has been invented for situations where images may not be displayed.

Alternatives were not meant as menus for users, no more that one would
expect a menu in an HTML bitmapped browser besides each image, to know
if you want the image or the tag.  Oh, one may argue that we have global
options to tell the browser to do _as if_ it was unable to display images,
or to delay their loading, but this is more a change in the description
of the overall environment, than the intent of a per-image menu.

In the HTML case, the decision is taken by the browser, and this is the
clever way to do it.  MIME should not be different.  I would expect that
an intelligent MUA would be able to plainly and silently make the proper
choice when given alternatives, given some prior knowledge about my overall
environment, and just not bother me with buttons and unneeded devices.

Of course, in the development process, one needs to study how MIME works
internally, and there is even some fun to click.  But if we look beyond,
the real goal is to present a MIME message almost as simply as it is
done for non-MIME messages.  If one can readily say, just looking at the
multiplication of artifacts in the Article buffer, that here is a MIME
message, or that this one is not, I think we will have missed the goal.

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: Pterodactyl Gnus v0.46 is released

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Or, even better, a more general way of telling Gnus which types you
> want to have buttons for, and which types you don't.

I've now added `gnus-unbuttonized-mime-types'.

> Of course, there should also be a function to buttonize everything.

Which brings us back to which keymap all MIME commands should be put
under, which we didn't really resolve last time.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Pterodactyl Gnus v0.46 is released

[Lars Magne Ingebrigtsen]

François Pinard <pinard@IRO.UMontreal.CA> writes:

> Of course, in the development process, one needs to study how MIME works
> internally, and there is even some fun to click.  But if we look beyond,
> the real goal is to present a MIME message almost as simply as it is
> done for non-MIME messages.  If one can readily say, just looking at the
> multiplication of artifacts in the Article buffer, that here is a MIME
> message, or that this one is not, I think we will have missed the goal.

I agree with you totally.

The only bits that really makes sense in handling separately (by
default) are attachments, really.  Everything else is meant to be
viewed as one complete, whole document -- just like HTML.  So I'm
defaulting gnus-unbuttonized-mime-types to (".*/.*"), which means that 
only the things that aren't displayed by default (either because they
are attachments or because Gnus doesn't know how to display them) will 
be buttonized in 0.52.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

No more buttons by default?

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Everything else is meant to be viewed as one complete, whole
> document -- just like HTML.  So I'm defaulting
> gnus-unbuttonized-mime-types to (".*/.*"), which means that only the
> things that aren't displayed by default (either because they are
> attachments or because Gnus doesn't know how to display them) will
> be buttonized in 0.52.

Are you saying that, from now on, there will be no way of saving an
image found in the article buffer, without fiddling with
`gnus-unbuttonized-mime-types'?  Or of hiding the image from the
buffer?  Or of saving the textual types that happen not to be
attachments?

All this is bad news.  I don't really buy into this equivalence of
MIME and HTML that you people so like to stress.  MIME simply provides
a clean way of merging all these formats and a clean way of specifying
how you want them shown; it is by no means the equivalent of a markup
language.  Saying "MIME is like HTML" is IMO missing the point of
MIME.

I agree that MIME should be seemlessly integrated into the Article
buffer.  But I don't see anything wrong with the current buttonized
approach, especially if it were accompanied with a decent
Summary-based viewing mode.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Mix 2 table spoons sugar with 1 spoon salt.  Put it in a bottle
and stick a fuse into it.  Say "Shit!" when it doesn't detonate.

Re: Pterodactyl Gnus v0.46 is released

[Kai.Grossjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:


  > Anyway, perhaps we should just drop the buttons for all the
  > text/plain parts totally?

I don't think that's a good idea.  It should be possible to see the
boundary between parts.

At least as a user option.

kai
-- 
Life is hard and then you die.

Re: Pterodactyl Gnus v0.46 is released

[Kai.Grossjohann]

[-- Attachment #1: Type: text/plain, Size: 238 bytes --]

François Pinard <pinard@IRO.UMontreal.CA> writes:

  > Handling textual parts separately, with buttons and such, is
  > overkill in the default presentation.

Hm.  I always thought of MIME parts as a way to write the following:

,-----
| 

[-- Attachment #2: Type: text/plain, Size: 64 bytes --]


| I have written a README file which explains the foo thing.
| 

[-- Attachment #3: Type: text/plain, Size: 2 bytes --]

| 

[-- Attachment #4: Type: text/plain, Size: 32 bytes --]


| (text of README goes here)
| 

[-- Attachment #5: Type: text/plain, Size: 2 bytes --]

| 

[-- Attachment #6: Type: text/plain, Size: 30 bytes --]


| What do you think of it?
| 

[-- Attachment #7: Type: text/plain, Size: 271 bytes --]

`-----

As you can see, this message also has this structure, but I used `|'
and `-' to delineate the middle part, in the assumption that readers
don't have MIME.

Is this a wrong way to use MIME?  What should I have done instead?

kai
-- 
Life is hard and then you die.

Re: Pterodactyl Gnus v0.46 is released

[Kai.Grossjohann]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

  > François Pinard <pinard@IRO.UMontreal.CA> writes:
  > 
  >   > Handling textual parts separately, with buttons and such, is
  >   > overkill in the default presentation.
  > 
  > Hm.  I always thought of MIME parts as a way to write the following:

Eek.  Destroyed my message.  Should have writte #!part not #part...

Hm.  I'm trying again.

,-----
| <part type=text/plain>
| See the README about the foo thing.
| </part>
| 
| <part type=text/plain>
| (README goes here)
| </part>
| 
| <part type=text/plain>
| Did I forget anything?
| </part>
`-----


kai
-- 
Life is hard and then you die.

Re: No more buttons by default?

[Steinar Bang]

>>>>> Hrvoje Niksic <hniksic@srce.hr>:

> All this is bad news.  I don't really buy into this equivalence of
> MIME and HTML that you people so like to stress.  MIME simply
> provides a clean way of merging all these formats and a clean way of
> specifying how you want them shown; it is by no means the equivalent
> of a markup language.  Saying "MIME is like HTML" is IMO missing the
> point of MIME.

I'm not sure what to think.  I think the proponents of MIME/HTML
equivalence are correct in that this is closer to the original MIME
idea.  

But I worry that this behaviour will make us incompatible with other
MUAs that don't use the content-disposition header to tell us whether
this is an inline mime type or an attachment.

I think MIME-as markup may be workable, or maybe even the best
behaviour if we have 
	Content-Disposition: inline
in the message parts.

But I think Gnus should default to attachment behaviour, in the
absense of content-disposition headers, because that's probably closer 
to what the composing MUA expects.

IMHO, of course!


- Steinar

Re: No more buttons by default?

[François Pinard]

Hrvoje Niksic <hniksic@srce.hr> writes:

> > Everything else is meant to be viewed as one complete, whole
> > document -- just like HTML.

> Are you saying that, from now on, there will be no way of saving an
> image found in the article buffer, without fiddling with
> `gnus-unbuttonized-mime-types'?

There are always ways!  But saving an image found in article buffer is
no different from saving an image found in an HTML page, and this is not
something which has to be a bold part of the MIME article viewer.

What you ask for is dissecting, with a scalpel, the intimate structure of
a MIME message, for removing or copying one constituent of the overall
presentation of the message.  Use `C-d' for that, combined with saving
commands.  I even guess Lars chose `C-d' because of the first letter of
the word "dissection".

The problem is that we are so uncomfortable with MIME that we desperately
want control over everything.  In my opinion, the uncomfort might come
from the fact we do not have many good MIME readers.  With a real good
reader, I do not think that the urge would be so great.

Intimate operations on the MIME structural entities should be something
driven from aside, and not encumber the reader.

> Or of hiding the image from the buffer?  Or of saving the textual types
> that happen not to be attachments?

When using an HTML browser, do you ask for hiding images from the display?
There is no such strong reason to do so.  Do you ask for saving substrings
on the page?  You just cust and paste them elsewhere, but you do not ask
the browser to have special provisions.  Just think the same.

> Saying "MIME is like HTML" is IMO missing the point of MIME.

Maybe we are not missing it that much, after all.  Yet, there are indeed
a few MIME aspects which are widely different, for instance, like part
reassembly of a file split in many messages.  MIME attempts to be many things
at once, and this throw some confusion.  But surely, it is a rather frequent
use of MIME to produce multimedia messages meant for unified presentation.

One cannot expect that a single paradigm will cover everything at once that
MIME tries to be.  Maybe that some of the weakness of many MIME readers
comes from trying to build on too few paradigms.  Better use many paradigms
as needed, and implement each of them very well.  It looks likely to me
that an intelligent reader could determine, from the structure of a MIME
message, what is its intent, and choose a suitable paradigm for that intent.

> But I don't see anything wrong with the current buttonized approach,
> especially if it were accompanied with a decent Summary-based viewing mode.

Hiding images or not, or saving images or text fragments on disk, is not
fundamentally what one would expect from a unified presentation.  If I was
hard debugging an HTML browser, year after year, maybe I would add a great
deal of buttons to trigger and untrigger things, to help me in my job.
I always had the sad impression that most MIME readers are kind of never
ending debugging versions.  Even if fun, buttons may be close to noise.

If the "decent Summary-based viewing mode" was giving access to the
intimate structure of the MIME message, it would still be a debugging tool.
MIME was surely not meant to be dissected all the time.  There is something
inherently not healthy in the concept of constant surgery. :-)

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: Pterodactyl Gnus v0.46 is released

[François Pinard]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> It should be possible to see the boundary between parts.  At least as
> a user option.

Like the "View Source" menu selection in Netscape, say, to see HTML tags.
You at least have `C-u g' available at any time if you want to view full
MIME source.  On average, seeing boundaries should not be anymore necessary
than looking at HTML tags.  It is a kind of debugging information that
you should not encumber normal displays.

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: Pterodactyl Gnus v0.46 is released

[François Pinard]

Kai.Grossjohann@CS.Uni-Dortmund.DE écrit:

> ,-----
> | <part type=text/plain>
> | See the README about the foo thing.
> | </part>
> | 
> | <part type=text/plain>
> | (README goes here)
> | </part>
> | 
> | <part type=text/plain>
> | Did I forget anything?
> | </part>
> `-----

Suppose I write:

   To check if you C compiler is working, put:

      main () { printf ("Hello, world!\n"); }

   in a file `hello.c' and do:

      make hello && ./hello

Of course, I expect you to either copy, or cut and paste, the two code
lines quoted above.  I could also, using older methods, have put them
there shared or uuencoded, so you may extract them exactly, say, or at
least, force you to realize that I was sending files.

I would be tempted to say that if the sender wants to really attach file
README, then s/he should do it that way.  If s/he merely quotes README as
text, then it should be nothing more than that.

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: No more buttons by default?

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Are you saying that, from now on, there will be no way of saving an
> image found in the article buffer, without fiddling with
> `gnus-unbuttonized-mime-types'?  Or of hiding the image from the
> buffer?  Or of saving the textual types that happen not to be
> attachments?

There will be a command to display the article buffer fully buttonized 
(when we come up with a MIME keymap prefix -- I'm tempted to go with
`K'), but I've been running unbuttonized for half a day now, and I
think things look nicer without buttons, so I think Gnus should
default to not buttonize.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: No more buttons by default?

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

> But I worry that this behaviour will make us incompatible with other
> MUAs that don't use the content-disposition header to tell us whether
> this is an inline mime type or an attachment.
> 
> I think MIME-as markup may be workable, or maybe even the best
> behaviour if we have 
> 	Content-Disposition: inline
> in the message parts.
> 
> But I think Gnus should default to attachment behaviour, in the
> absense of content-disposition headers, because that's probably closer 
> to what the composing MUA expects.

"Attachment" behavior means not displaying the part at all, according
to RFC2183.  The user should be notified that the part exists, but it
should not be automatically displayed.

Not that I think we should look too much at what other MIME readers
do, but this might be nice to know how others do it.  So here's
today's assignment:

1) Find a MIME mail/newsreader, and
2) See how it displays the next two messages I'm going to send.  These 
   are called "MIME Test One" and "MIME Test Two".
3) Do screenshots.
4) Post URLs to these screenshots.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: No more buttons by default?

[Karl Kleinpaste]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> "Attachment" behavior means not displaying the part at all, according
> to RFC2183.  The user should be notified that the part exists, but it
> should not be automatically displayed.
> 1) Find a MIME mail/newsreader, and
> 2) See how it displays the next two messages I'm going to send.  These 
>    are called "MIME Test One" and "MIME Test Two".
> 3) Do screenshots.
> 4) Post URLs to these screenshots.

The word "ewwwww" comes to mind...

For a minimalist approach, I just fed each message to metamail.
Metamail works on One fine, showing the parts in sequence.  Metamail
abuses Two so badly that it shows the image/jpeg, but doesn't even
acknowledge that the other alternative parts exist.

*hurl*

Screenshot follows (it's only 8K).

begin 644 metamail-test.gif
M1TE&.#=A]P$$`O<```````!D`%A<6+B\N/C\^'AS`0(%`$!``/@#$R\``!0`
M``@``"B\`3[P`!3_``B_`-P"T#8`-A0`%`@`"+N$I$!<[Q0*_T!`OWQ\A.[P
M[QG__T"_OWPY)V!]>!`%`@A`0.RP^/$U+_\4%+\(")B\*/'P/O__%+^_"+0"
MU$P`-D``".R$!_%<-_\*%+]`"'S4*&#P/A#_%`B_"'L$-F``@1```@P`0`#X
M;P`O```4```(`'P$#>X``!D``$```'SX;&`O`!`4``@(`(0T'%SQ-PK_%$"_
M"&$%X'-U[P4"_P,$0@``:@``!P``""#X-C8O@104`@@(0%P$;P(``(3X#5PO
M``H4`$`(`,!,;/'Q`/__`+^_`.D%)'QU-P4"%$!`"+#HX#4V[Q04_P@(OR#,
M=#;P:A3_!UP$^`(`+P``%(2$@UQ<``H*`$!`!>SX*/$O/MCX;^PO``,4`+`\
M$#4^`!04`"`;;3:V`"@$$O(``/\``+\``"'X#4`O``@4`)Q\[$?Q[PS__PB_
MOP`%-@!U<0`"!P!`")P<'/(W7_\4$PC\`:#P`"S_`$"_```$B@``L0``$`"$
M_/)<[_\*_[]`OQ;X/>PO90,4!T`(")CXT/(O7)P\2/(^]?\4_[\(OP@`_*``
M\BP`_T``OP`P8P#\?``9!1<!#8(```<```@#`*```"P```$$2```]0``_P``
MOP`$2`#X;`$O\@`4_P`(OP`$`&[X``#$``#Q``#_``"_```%``!U`/\"`+]`
M`".X2`$V]7Q,\@#Q5@#_%P"_0``G`P!X```"``!``(14O#GQ\`#__P"_OPPG
M`@AX`(3XA%PO7``4"@`(0``H,``^_``4&0!DO`#Q\&$G`'-X``4"````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M`````````````````````"P`````]P$$`@`(_@`)"!Q(L"!!`083*ES(L*'#
MAQ`C2IQ(L:+%BQ@S:MS(L:/'CR`?(JPHH*3)DRA3JES)LJ7+ES!CRIQ)LZ;-
MFSASZMS)LZ?/GT"#"D4I<&1$HR&3*EW*M*G3IU"C2O6(5.3$J@Y'8F58<JK7
MKV##BAU+MFS6K0N['D6K4.W(`7#CRI6K=J[=NWCSZMW+MZ_?OX`#"QY,N+#A
MPX@3*U[,F''=OH_Y1M[K5J#?R8TS:][,>2X``)WS?@Y-NK3ITX[?0E8MF35E
MK997QT9-N_;IT;9SZ][->S/FO+_Q/DX+MS*!RZY[*U_>=S3N`9^?1P<-G7IU
MN-.Q@WY^W3EU[]6Y_L?-KAWW=N_6F:M??S=X^^3`51]O7QSV_-:SV>M7'[W[
M]_/:71>@>>?U-UZ!_DWWGV<+$BB@@_M%R)Q[=E$XUW#"U5>490T),("%$H98
MFH,0'CC@@@G:!5Z*`MXE'HDHBB?BC*>!&!=F`WE(EWP9?FC?`/?19R.-1"X&
M(WD*GEA>?S+ZIV2`>+W88(SI%6FE;_`1H...^0%9W(4\TN?CAL<%6>&89EZI
MIF(P,@AE>";*U>2**[:H8I5M/ECEFGP>]IN6%28WWY8:SI?FEVB^I65+:/;I
MZ&%,`NADBP;J:2=XD5)*I:5YEOCHIX$-V:A<BQ(ZZJ$?%@J?<*N"ZFJ4_I*&
M9UVFV#'H*::2<D>>GM(9"&&3KP8+9I?Q$<MJ;*CJ:!QRQ@KKK&YU/BOM;J)6
M&^:9B38;J+;3=AM:M-Z&6YJUW')I*$NJEGMCJ^*V:R2*[L:K&;FH;EOOL%JJ
M6ZB\_/;KKX3T,GNON0C15.I0"">L\,(,-^SPPQ!';/#$,QT,D\429ZSQQAQW
M[/''((>L4[X`$%#RR2:GK+)9++?L\LLPQRQS6/:A;'/*)<^L\\X\]^SSSV3!
M=O/-*P-M]-%()ZUTTC7C[#3*`T5'4,Y1%T2U0%=+K9#66$_]V4)<%[WUU%Y?
M3;94.4.-D=D59<UVU5V/'?7;:9O]-MP&V8VW_D1U9SVWU`KNO3300C_M=-%V
M^TVUVE];#;;5B^,=>=QJB]VXR6S???='D4.].42?6[3YY`_1+7A#FCN^]LII
MJSQZUZ$/'G/30Q\>-^R2LV[[Z7M7#G?8N%-^N>=B%P_[XL,W/KG6)R/?.N)@
M,ZX\U\Q+C[SJ"7T]_?5G=X^XVWWKC;7GG5_OM^.=8ZXZZ;+W7'CMS]^>>_"Z
M8Y_W_5Y[KW[]]9^O_]STTUOZCG>[V*6.:*X;&P(+:#_T64YPXH/@Z3+W.](I
M+X$0C%_S"JC!]OV,=H:K'`49:$'\9<^$QO,>^_XV/!1VKWG5NV#X?`>ZQ]EL
M.O+#G/8.A\,<ODYX_BU4H0O!)\'Y\:]N^O-?!`/H09^]+X3R&R$3_<>['/+O
MA?>C8A1=",#=]0^#O/N<&`VW/MW5CH'_RUT)L3C$$R90?$$T8P,IV,'EI;")
M,`,A_,HV/NIA+W`ZC-X,=;B]/L8QD&<#)/"JECSGL8]Y>;M<`TW8M_P9LG\Q
M_)O<7)?)/EJ1>MMSVR?)UT%$)LZ/FO1D%?&8QPWM,7X\B]TD9R9+5NYLA;;,
M)5?(],H[ZO*7P`S+(H-)S">>L9;$3*8RE\E,D.@1BH9$YB:E.<QF6O.:V&29
M,<FX1#>BKFVKS*8XQTE.I3SSC+UK9/0XR4CSL5-]-T1C-4VY/WB6\Y[X_K3E
M-HD6P36Z,8XRI!PWQS?%;Q*0A_E,J$*7=DXR&E&6_EQ>^;HH1R!.LWB27*A&
M-ZJS?2*4C5=<7T0?F$1&$A2D`PPG1U?*4K$T=('?<]XZ*XE)F:I2HC@#I4TS
ME]&6^O2G4?$H\?C6$5R&E*@UM")0E\K4C[S4BVCK:2J=,L^F6O6J%!$J&+'*
MU:Y:]:DBE&H*D4G-"M:QAY"K:AKYZ-6V+E6KI32>-#>YRI'2CR%E?9Q2W<I7
MA8(UI.F3I#IOJM.M;9"#]G0($0DKUL#:M*^0Q29<HWC!@YXOI;#<JT,#2TB\
MJI&+6`RH9B-+6EW^U728320.I5BZAYI4L2RD_JDO4PO(TMHVF),](CLK*U`V
MQI62KH5H77O[QXK>]KBXY244P^K.PVIPL"=%)'#I>;QY+A:M]8QD*=6*W.XB
M+;=S3>3JO$O>\E[DM&L+KWG7RUZ2N'*YHVVO?.<[%?1&,R3J]6Q\+\)=NNK5
MOT6-KNC8ZD,MPI8C^:5O4L"KTJ1Z$\$-YJ^$,Y)@_>XW(D;=JC`57!;[/G"P
M.U0E%R$)7<CM#Y1/>ZPW#YM8$K<N>?F#X6-=;&'*OGC&.,UNXOZ+Q*FB3\45
MYC!'&'S)$\N1<?_-XHN_Z;NABO:.W'-R.RT[OT<6E[>31.V2@8OD(FO6KG+=
M,O2$#!8/=Y.SPDTK_@VK*='IJ1&[Q15>;(VK0BW&,,10MM]JM1M:*K(VSKKE
MLA')[!4BD_2S77XPG6=)VRNWEH1S%#-(?^?`2:.PA#\\ZIA+*F<T!MIVF26T
M5,R<9=[*5LWALQR;S4K3-@M2GB`V<EI]',I49MBL+%0U=`M;8!QS$L?;Q;*H
MZ_O>/?H2G&6Y]7B/[>`@)RW(SAZV4SS,ROZ*3JQMP[:TMWV48D,SVMP.-WW-
M;%T*"Y;'$Q8QK_W;V!ZJ=9`.]N$LQ=U70VNXP9F6M*4QC.G7CM7`J!UT=K],
M-NX5E-ZEI?;S[CQ5[B;:DJT.(R9W*W%<`B_8*1UMO_M]880WU=Z9A:4__@WK
MZ8*#6M.4I;AT5ZQC$XOXBQ1%]:=3ZW'(*AR((H=SDHV*1#N.L8VWCC*3PPCG
M?+N6B36OM[>/*5X[0C7/E1:T0'_.Z:`?W;@6+[F>-WUR<"<]G^1NI,'7+7."
M6[2N[A:EC\M62'7O.J,J/C`A5^CUK^/3WANIN]'FJG>[CUNYO?2[X,F,]\$;
MGKW4/KSBRUOXQ3O^MHE_O.1)V_C)6[ZMD;^\YKE:^<U[_JV`A^_G1__5I0^4
M]*@':N93SWJ_FIZ?K8_]1E<O^]IGL_.VSSTS::_[WA?S]1_UO?"7R?OA&[^)
MN#^^\@=7_.4[_VC)?[[TG1AZ8T__^M\%_E"Q_L_]#U8?FG.7ZU3(:E`,+SO)
MH!V+GY$-NK[C%>#G7RNS%;U0O"L;9J'C>_SI+W^S&!B_:--_[#=OZ39[WX=.
M)&1P*S=K.;5V+N=JG94]Z\9P+Q=:]42!2F9K1A9K)>9;CG10$CAVQ'-N#EB"
M+?90*`:"-!:!%<0Z:X1B[L=*]M=%(\=R3_9S&1=?2H11`CA1)"5&(;>!8N9<
MQS9R:F<Z@D:$GI9_)X1`5O9'05A94N2$)E=1VG9/B0=F"_A9U:5M&*=2X--V
MNJ9`)Q>!5)=J,G1C@(-K37A%.QB"%JB$+LAFPX1.3_A""[>&<V1R=#=G]U=.
M,[B$_-=HC]9CE#96_G=51H?&AUA'7!:(.VDH;Y+H0$_X<"P'B0TH<--%B>\T
M9IA61_C39&48/'#TAY)U@`XEB*9D7:96@8=H3]CEA3L5-K5&AC6E@!Z(9Z-T
M5MAF/1!'=+&6B-+%BE*%4Z<6C&P79I,8<6?78E=XBB0C>C&8=QW'3-VT--.8
M%-D88/6'BC#5,L]X3=>H--L($N5H6]'7?>IH%LVWCN[H4MIW;^\XCT'CC4]'
MC_CX%>F8C_RX%.W8CP#I3/$8:@%9D.9DCS1DD`KI5`-9C0OYD!+QCQ`YD581
MC<9VCA2)CQ*9D1QI$/O8D2"9(P@Y?R%9DA]9DAVYD2B9D2>YDA2IDBX)_I$M
M&9,/"9,TJ9`S>9,&:9,Z&9`YV9,`R9-`R8\_.93Y*)1&28]%F93SB)1,Z8Y+
M^93KZ)12V7U1697<1Y58>7U7N973IY5>^7Q=&9;.!Y9DJ7QC>9;'9Y9J.7QI
MV9;"QY9PV7MO.9>Z%W:Z&&%(8T#F)H`#II<DMTX0]FCIQY4->6@8R3+E>(Y>
MAX.#*7<$^)4CV4\7N%B1-(<-]W:_]FHW=6(3Z(-;F$$`Y&NG]CTJ"&,$F421
MF%BKV(NDY&76EGN!*&LH9U)(-HZDJ'601F6(B%CW6'XP)66ZV6.WN5>!XVY3
M!GZ.&(IP!&!K.9F`]DB-E6*=-(S5,V=MA'2G_F17L7ED129V!$F<X3=PY;=H
M_`1)Z&:&:B:9%OEMT2EQ6?2;`N1O.NAO73:$5U>-:$:?B]AT03@1.SB?]ZE4
M/7>(B9:829>%55:+TT6!:)5V<4=@Z.F"N49=.16.G8ES;O>?H49VY6FAL`9C
M))=JT06A:'F8"$IA@.E!IKAPP)E+*>IQ<LD4W=E$L7E(AA6C.EF7=FE[>!DS
M3*BBY^=L%?9_BD5-.AJ9?,E_!,9G.;I>(.>041&D_B<61OJAD`D6F59C2DJ8
M@.9=-[>9ESBA2"BFSD6'';B@;)5A8G=1UIF<K)F,F1B:6Z2=J`-BY(.9<YJ7
MO=.G<VIV)4>EY!6E_J/XB(4J<$HHJ#QW=98H1.A6IJ*UI3=80[_UJ+:IG)F8
MIP\642*W<W[JG,@5IHVJ<H>*B9WE=)YJG)MVG/+9?Q"HBE[89S=:A5FZG^>)
M9Z/JB9U:IYLJ8%3'>"C:=%6T0P-4C)L%<ZE3JG?5APE9IT@(=\%U8,4)H(MF
MJ9AH?=/:BS&&F.&T8U<J7S_JBLSI3FUX218$A"9H8PT'98(U.C>$C*7Y@&PH
M=Z:8F:"HH<;(I5Z$JD\J4K\ZJ,'ZER3I5O6*3P6+5`/;7DA9HVW%L.7DL.V7
MI*#7GDS7HT0)G=<&L2-FL?16E'U'I!QK7D))F=;)BV-7F6(J=0D;L@EE_FC'
MN5HPVT+W6H93N&7?NGT2R[+,A[$#*#E[YEN;:(CQUJPZRU(>&Y_<*IXS)WXV
MQ)]%ZU,C^[,I"X,41:8;ZJ8K^[18&+![IXE::W,\NW<8^K68Q[5D:YCY`E]$
M>[;/2;&GQ[;L.1*]E+-P*Z-F6[?+-Z-X*WD\NK>/I[=^NWA]&[B*![B$:WB#
M>[B#9[B*ZW>)V[AVQ[B0FZ!W.[FU)[F6BW"/F[F:&[:<&WN;^[GAAKFBNVVA
M6[K2IG!CBZ6%F;7<J+&H.S,NNZ+HQZ12ZA&Y&KM,P[,\54N.96NKQH$WIH&:
M^:VZ"WUF:[7T2IO+*:\%-[Q=AY^&2+?'&Q*9_I>[C-AFJ1FB1)B&>GBAN$J[
MU=M17$MSY'FM]MF\C=B]_[FO`C:^'J2Z0.99&(>+"YJ7O1NBHRF^\#L[E:NO
M&^:7_0N-<JNV>QF9`WQ[_YO`CD>Z#(QX"_S`A^?`$@RL;@M[%<RWGIO!$QS!
M'!RY&_S!@G>Z(ARJ(5S"7T?"*(R.)[S"=GO!P>?"()RV<RO#(UR^,;NZ-MQ=
M%+S#?*7"/NQ6/1S$7@7$1-Q50WS$6&7$2GQ5D?=G!7B[`)Q>0VJ.H)6L?$.]
MB:EVS$:]/S6;`NRE`,@Y54S&8DR[V_L4$MNBG4O#!BR:K>:+C*6`P3N+:4J\
M;SA_R'G'G<F@[6JF_AZJFM`+AS5UFE/+QY>)BS6(P!Q&J')FJTX[A41GIV"8
MG%I88Y-*ORX:9^&[JB%X5@2:OCZ8ISG(QI;(K[9+>&$;H)<J8[(ER>_7A2$W
MG4@W<5Y:/F@ZH._)K[6U=<+(R;^&O^G;FN%(A7BXI*-[M_F*OC\45XLJ;!H&
MJ9_&FMK:=2_J="^HRVO+J]OL<Y/XR!)$-P<$6*_8GZ:[P>2JO!A8F1&ZBQ!'
MC/K[I1(8SY]\1*3Y<HA\2OM%BVN:R'-,:^G):Z_JQ5#KP>!HI>4<;HOIN"WL
M,EJLPTW<$4P<T4RUD1"M9R08<_KW%7IWL%F<7VD&JBQIT*U+K:KJNDVQ_JBX
MR[_Q9M+[EY(-O:FK^::=EM'OZX%-^KSIVJSYNZ?MYIG-Q<X6QF(AMH)$+4HR
M9J\@J)0DS6@;:(/V;-/OJ9M/3:`ZEV=/1H;S^4ZY*W2;G*FTB:IV9LE'&=.7
M]KT`O=3PA[6+W(CE.F)H+:ZW6*+M5&ZPYH=.:YH9-$@>?:(PO'W-EM>JZ,N<
MUHE@9K[[EK2UN[Z.MKR)N&-/EW4?)L]0:=82&M</^G9T5[Q7FZ$I"Z`0VF2K
MIJ$6&J\:V(Q&[:0KY\>MJ)%-+3/0UCY]39C1-ML%F<2D!;MWVI@7O9.O3=$*
M:]G`'=Q_+8_#W<C"?=PB^]O*#;!N''C-K<K%_IW&T0VER5W=)CS=4HS=E'?=
MW,W"VHW2WZUTSRUZ^+R'2MVOZJK>[)J"=!JC^M:S`UC-4'?3G:AQ[,:_Q^B'
M.4S0NY>\+G=P=SA$ATUI>0R?)?V8&!S%U(BU64K5BVW.U.K-6`VNJTRKB,UU
M6_>L/76?JXG%/Y;>$'C47\VN>IK9!>IV!*@]KWR-?G9=%[>_%XBR\/>[_FG=
MX;W6;CUP6UI@JCG8`06M\WRHTPK6^ZS5,!>?HOC-G&AI9T;9L`Q0-OOC9O1<
M)^7?Q'?ANYS0@/JI='5_<MB;X$NBI,2G9]S*R)F,M]J';OJ@A%U$ZD;8W#G6
MB(K>SHT0@:?CUBSF_AL;RI_DR;7\;X]MX$R.WTV[9@5ES!*^F^3LY_"I;]/+
MA7#^6H0HWDZ\RJ'$YN,)S^&G2)F>3L!F@B1>H3'ESJE<R%7[O63.Q]K;V3U-
MS+]H8LQHIF57ZIUMP7@NC3^ST3V#Y0;+TMR&VW"IVZG+W./=W>6-K5>-L$CJ
MZ\<^;<K,N@E^B<_^>\F.J9;)BH9-XUP]-%_8KT=MZ=5^%=$^V,SIL[GIGE7]
MFPF8[N,.[=>.@-.<GH$FLR>KG;0,5;W][NZ5XU,-=0#%GT].BB1KGOP>5)Z;
M[:Y)ZZ@-KP25U*ZNV@=_D/Z.L!JATN)-?ML]\1`A[')-I_BU[QQ?D;E^_I$C
MS\.8#N)AG+`C7M?%N.RMV\LGGQ;EB^`,;G2"&-)GSL@S3R8%#-V4R6)"_<]R
MS>+H;N9G;<=G.*\C#W*MB&4SVZ&'CF@L2.V(_J*!/O'7N^/!?/6!G?.T;:)'
MCKX;/]RS2_#,V[Y?C?.Z%=+-#*AV.//RN[^)FMXEFN^S[LH[QZ#GVZ?MS.]'
M:^G.WO/6Z]T!3OC=6/&('UEXZ7X=#>R[+;!37/;Z)?*V[N-HS(V^=_9">NH4
M8=L['_KF9\603]GJZQ6##\'Q?JPZ35AZ"M>#3(=`3?=#?U&HV<>QC]0L*-!]
M_\TK2-/=3N5C:IDA?MYTB<-N9LU=;4/QW>24_G[EM>G5Q,6^L.KE57[2:=2]
M4'VN4HU27IO)E"^XO&OG\@Y@4BOJK$;7LDSOTRNU"<G%8]CIPU5G?,K/:OT_
M;-_6YIOZRZWX`P]^``&`P$""!`46/$A`8,*"`QD:A)AP84.)"AM>=`@QXT..
M!R=>K$@Q(T*+)$=B+'FRXD.3*5FFA'E2I<.0+C7:#/D2Y4Z>/7W^!!I4Z%"B
M18VB%#`PJ<6)36VV-`C`HT:I.JM*I8FU(U:,.:MFG:F0:U>N7B66%2L3[%J:
M6<].50N2[=68=.>._:HVK]BS)??^13LRK\ZCA0T?1IQ8<>&E29TZC7F8\&*@
M-1=;/HJ9\F;*DW]Z_N8<6O1HTJ65GF::&K)IUA3';MXK^75KVK5MW\:=FW1C
MU;TCZP8>7/APXL6-'U_,N_?CJ+.A%HU-6'-0AH#?\NS8L_K.JPOM?A;Y'#1R
M\N7-'^?-_./VW^V?MYQJ]>90O!'MQVT[7^_*]W6YD^SKOM3.([!``X-33KT!
M!5OK.^M\^NBWP`;3;R.JUHOPI0Q!J@\NOV;C"+N;5N,/OP-/1#%%Q-);SB^3
M0H2I)L\"D]"W!:5#",,/)UN)/1>?JJLZJ^B2<40@540R225_2K#%"'^T2\C8
M1#12KK1R<J]&`"L<T<,<OYI.O/_"`G+#)<]$$TT6%8S10@87["^N)^%[_FK.
M\,0\\LXB]6QSIC#;]/'&+-,DM%#RFE3P+46C:JY1LOX:<\<X^2I+R"]1ZNXN
M&&5ZD"WPW,)L/$-')36W-5L<E"A12TWU3E9?A356C!!U4E9;;\4U5^%.9:Y5
M77\%-EAA>Z*5S6&/13;98WGU;55EGX4V6A6+155::Z_%]D1F(7,V6V^_!7<T
M:GL-MUQSSPUMVP&[1;===]\E8%P;X:6WWGK57<]>??=%5][5^`4X8&GQ_5%@
M@P\>UE\X$6:XX5@)]M)AB2<F5&$[*<8X8VU/2]1$C3\&V3B+?0VY9)-9@]CC
MDU=F65S4.F:W99EG%BIEDFG&.6>>1HY99Y]S_K:YYY^';IEGHH]&NJ"@DV::
M:*.;AAIHCFN].6JK)7[Z:JU-7GIKKT'.^FNQ)^YZ;+,;#OMLM0,N>VVW]\TZ
M4PU?!4WH_%3.;-+/>+3;52JM?%NTMO.4M>]/23.<2ZH2$U6^P`5_N=9-O6/4
M40Y=PBOSZ]KRR#G+*:Q4\\J9VKPKUQ@M72M/8XPO]7S_;C"M*QW][O+.;R_]
M<<:F9G-R#_^T<,--Y8)KNA))?Q/P`"^&T+X0BZ_RQ?CN&Q),"C>:?LZ(PP/1
MQ,0#3WM/UN5K*DK1W;H[4\#]7/Q+\6\7BC_<TX_2=-F]&\Q9'[5?]WI,+Z01
M^G2WNWA)3B_1FQOQ_A8FIN/A[7AFFAZ90D4=Y^'$;XZCG'_H0Z?G":I@TJN3
MFP@W0)^$KTKY\UR=0C<_`7;J4;3K4G/@AY,I88=&+.P4C+;GPN9=2H,["A!9
M@#@Z\WW/;(,S#_!8I<0WS4AQ:#+B$2/7L0/5\%96Q!03L4A"8"&1BU^\5MRV
M&!PG&J9O@3**W=!8&?U%,8VP^Y_]N)-"OLS1C>5JV_:&4T;BW'&#3X1C#X&#
M(T&NSY!Q5)[&PE:\%)J%3'2J(_(HE<7S)5)VL?/>HN0XPTMF<'8<0DLEU_=`
M!YY/=9^,I"=/.<KYM,YO4+$,'S&61Q$F4%#&TT\&]0A++KU/0(1460-C_KBN
M2-UOA*;[W>&$1[6(1+"1D,0<IXH9RT"2;8K,=!$N46DFD6!HE;MLI>*>I"AR
ML3)2G"S3W>1(PS&ZBGF&E!^JB/1+1'Y(FO=<9^?TYL=PT=*#MK/@);>TS";&
MD9O=A&;PIHD??4)3F/8C:/P"*LAE4O&6ZG3GO])93%16S9H%-*`F(TDEP+0G
M0V`:9A8ME\]*OC,ZTBF?*0%HP["T$X'QDVDMT>>5++&$?\FCI)7&R$]P>;$R
M@#08$Z6E5%4A=65IHP\=&6;3:U$UC5(M&N_D"4:N9@NJU*E=87S:5;+>QJB'
M4XSAB%I6\%W36$V%9`Z;F;EFHFYU1F(J6]U6_C:Y$<FO'6*?3B.SO`_RJ&!K
MU>O0OGI4Y<TSKI:TIT0%E%BNGK60;II<9),9V%=N2824!>-B]X92P;3TI#`L
M;>X<"EJR6O8\XF-M;"\BV@)95;:@=2W1`K!;WM[6JVZMUDA_J)(BVA&6=(R.
M=C+J.-I$$"6\[:UOPZC57J'Q-1$-9ST[>=/2NC.:G?4H="KH'NCN5KK3!2G,
M>%DD:DYJ.PFLX;_\IU&3=C*GDI)D*O'9D/(&X+S6\N=J932\5V8GE];E;IQ"
MF<N)ZM*I+^GO?P<&W'*.E;/#`V9V.>H>V'IOKBO$K&/_>)$(2QA:`0YGB=J[
MSD=&#T^?M?#E%H:E_HC9DL4%*;&)E;7(%4[P<\CM,:5FV%<4PJ>XR'1=?5#K
MPT/BN+PZ?E9NC=,MQ,+&*#F&\K(H/*^H83G+PI+RE\6,H"W3=\QG)DZ8T;SF
MUM"6S6]N,W6;!6<ZFZK,"ZQSGG<C9V[IV<^F<?.?!4U`QU"MRH.N<Z`1O>B@
MJ)G1CT;*G=\):4KOC,_$K'2F@:)H36?:T9U^-*=!#>E/CQK1HC;UHDN=ZC^C
MFM6"7O6K\^QJ6>LYUK6&,ZUQ3>=;[WK-NO8UFWL=[#$#F]AG'O:QLVQL97\Y
MV<TV,;.AK>-G3_N\TK;V?ZN=[=MBF]N^W?:W6>MM<<<VW.5.++G13=ES_J^[
MK.IV-UO;'>_*2CJ\]#;WI5^';S3#F]^AU?<'_^UL>Q]ZX&J;]\$?YV^%ZR[A
M#=]KP2&^[("#<^*R9?C%U_9PC8\MXQV78@&I:'"06^WC)?\:QU&NM9.OG.45
MQYO+N]IRF4=-Y35O&LUQSK2;[QQI.O?YT7H>=,5*G.CRAOF]CRXVH"]=9T-W
M.LZ:'G6:09WJ,IOZU;,J<D-K_8M9]_K)K!YVKAF=[`M/.LG/7C*PK_UC8W>[
M(LT>=X2GG>X13Z\![UYWKO=N[WQ?BGK_'O)"^WWP'I_[X;<&=\4CK.V-/QCC
M(2^PQT^>;7:W_-4JGWFX89[S4-O\Y^_E>=$G_BWTI7^7Y%$/K].OOE^D=_W/
M6A][/,*>]E++NT5O_W3;[WYFL_?];_N^U>#C/O!Z+W[5>Y]\L2>>^4]=_O-#
M!GSI1SGZU9=[[K&)?;9?G_L4H_[W$^9]\3LL_.7O(OG1[WCGK_^CA2>^^S-V
M?OG?2O7U!W.\CJ][_)L_*?"OKOX#O_830(.YOP+,%?I#P%(YP`6T%05T0$-I
MP`B$%0BDP#29P`MD0`+40'K)P`Z40`X$07?YP!'$0!$TP7,IP11<$@MD0119
MP1=$$A>400-I#`'`P1S4P1WDP1[TP1\$PB`4PB$DPB(TPB-$PB14PB5DPB9T
9PB>$PBB4PBFDPBK4"D&C6(H:U#*B"`@`.R`4
`
end

Re: No more buttons by default?

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Steinar Bang <sb@metis.no> writes:

>> But I think Gnus should default to attachment behaviour, in the
>> absense of content-disposition headers, because that's probably
>> closer to what the composing MUA expects.

> "Attachment" behavior means not displaying the part at all,
> according to RFC2183.  The user should be notified that the part
> exists, but it should not be automatically displayed.

Hm... one thing I've done a lot, is to send stuff like eg. compilation 
errors as text/plain parts with c-d disposition of attachment.

The idea has been that the receipient would see the text to read
inline in the message, but would be provided with buttons to make it
easy for him to save it to a file.

Re: No more buttons by default?

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:
>> Steinar Bang <sb@metis.no> writes:

>>> But I think Gnus should default to attachment behaviour, in the
>>> absense of content-disposition headers, because that's probably
>>> closer to what the composing MUA expects.

>> "Attachment" behavior means not displaying the part at all,
>> according to RFC2183.  The user should be notified that the part
>> exists, but it should not be automatically displayed.

> Hm... one thing I've done a lot, is to send stuff like eg. compilation 
> errors as text/plain parts with c-d disposition of attachment.

Add "perl scripts, C- and C++-source code files" to "compilation
errors". 

> The idea has been that the receipient would see the text to read
> inline in the message, but would be provided with buttons to make it
> easy for him to save it to a file.

Re: No more buttons by default?

[Raja R Harinath]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Hrvoje Niksic <hniksic@srce.hr> writes:
> > Are you saying that, from now on, there will be no way of saving an
> > image found in the article buffer, without fiddling with
> > `gnus-unbuttonized-mime-types'?  Or of hiding the image from the
> > buffer?  Or of saving the textual types that happen not to be
> > attachments?
> 
> There will be a command to display the article buffer fully buttonized 
> (when we come up with a MIME keymap prefix -- I'm tempted to go with
> `K'), but I've been running unbuttonized for half a day now, and I
> think things look nicer without buttons, so I think Gnus should
> default to not buttonize.

What about overloading `t' (`toggle-headers' I think)?  It gives more
details about the message without being as bad as `C-u g'.  And,
somehow, it was the first thing I hit to see the buttons (though I
realized immediately that it wouldn't work).

I don't think people who want to look at some `Recieved:' headers would
mind seeing the buttons (or vice versa).  IMHO, lets not have too many
presentation modes.  These should serve:

			normal article display
	t		detailed article display	`t' to "undo"
	C-u g		raw article display		'g' to "undo"
	C-d		article dissection		'q' to "undo"

Stuff like just showing buttons or just showing headers may be banished
to a prefixed keymap.

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash

Re: No more buttons by default?

[Kai.Grossjohann]

Raja R Harinath <harinath@cs.umn.edu> writes:

  > What about overloading `t' (`toggle-headers' I think)?  It gives more
  > details about the message without being as bad as `C-u g'.  And,
  > somehow, it was the first thing I hit to see the buttons (though I
  > realized immediately that it wouldn't work).

M-t is still free in the summary buffer.

kai
-- 
Life is hard and then you die.

Re: No more buttons by default?

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

> Hm... one thing I've done a lot, is to send stuff like eg. compilation 
> errors as text/plain parts with c-d disposition of attachment.
> 
> The idea has been that the receipient would see the text to read
> inline in the message, but would be provided with buttons to make it
> easy for him to save it to a file.

Right.  But that's not what the RFCs say that the reader should do.

Anyway -- even though I don't like the buttons much, there may be an
argument that it should be easy to handle MIME parts independently.
One way would be to have commands like `o' and `|' (in the article
buffer) work on the part under point -- if you place point on an
image, it's fairly clear that you want to save that image; if you
place point somewhere in the compilation error, you may want to save
just the part that contains the compilation errors.

However, the user must (I think) be given some visual clue as to where 
each parts starts (and stops).  The buttons are too heavy, but can
anyone come up with some other clue that would be less intrusive?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: No more buttons by default?

[Lars Magne Ingebrigtsen]

Raja R Harinath <harinath@cs.umn.edu> writes:

> I don't think people who want to look at some `Recieved:' headers would
> mind seeing the buttons (or vice versa).  IMHO, lets not have too many
> presentation modes. 

I've added `K b' to show a fully buttonized view in 0.52.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: No more buttons by default?

[Dale Hagglund]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Steinar Bang <sb@metis.no> writes:

> > The idea has been that the receipient would see the text to read
> > inline in the message, but would be provided with buttons to make it
> > easy for him to save it to a file.

> Right.  But that's not what the RFCs say that the reader should do.

I'm curious where you find this in the RFCs?  I've been browsing RFCs
2045 and 2046, and I haven't noticed anything that obviously implies
this, at least to me.

> Anyway -- even though I don't like the buttons much, there may be an
> argument that it should be easy to handle MIME parts independently.

In general, I don't buy the claim of equivalence between HTML and
MIME.  In HTML, the internal structure is hidden by the displayer
because the document is in some sense a unified whole.  To me, MIME is
more of a transport mechanism for carrying multiple loosely-coupled
pieces.  The structure is important, and should be displayed to the
user.

> However, the user must (I think) be given some visual clue as to where 
> each parts starts (and stops).  The buttons are too heavy, but can
> anyone come up with some other clue that would be less intrusive?

I agree that the current buttons takes up a lot of space, and aren't
the prettiest things imaginable.  But, I'd rather have buttons as they
are than no demarcation of the various body parts at all.

The only alternative I can think of is some sort of alternating
background color between for alternating background parts, ie, white,
light grey, white, light grey.  However, with this, I loose the
ability to easily identify the part number for commands like `2 b'
from the summary buffer.

Dale.

Re: No more buttons by default?

[Lars Magne Ingebrigtsen]

Dale Hagglund <rdh@best.com> writes:

> I'm curious where you find this in the RFCs?  I've been browsing RFCs
> 2045 and 2046, and I haven't noticed anything that obviously implies
> this, at least to me.

RFC2183.

> The only alternative I can think of is some sort of alternating
> background color between for alternating background parts, ie, white,
> light grey, white, light grey.  However, with this, I loose the
> ability to easily identify the part number for commands like `2 b'
> from the summary buffer.

But why would you want to `2 b' a part that's already displayed?

It's fun to `b' a multipart/alternative and see it cycle through all
the alternatives, but surely that novelty wears off after a while...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: No more buttons by default?

[Dale Hagglund]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> But why would you want to `2 b' a part that's already displayed?

Whoops!  I was confusing displaying a part with saving a part to a
file, which is something I'd also like to do without leaving the
summary buffer.

> It's fun to `b' a multipart/alternative and see it cycle through all
> the alternatives, but surely that novelty wears off after a while...

Wasn't aware of this one.  Sound's cool . . .

Dale.

Re: No more buttons by default?

[Matt Armstrong]

Lars Magne Ingebrigtsen wrote:
> 
> Anyway -- even though I don't like the buttons much, there may be an
> argument that it should be easy to handle MIME parts independently.
> One way would be to have commands like `o' and `|' (in the article
> buffer) work on the part under point -- if you place point on an
> image, it's fairly clear that you want to save that image; if you
> place point somewhere in the compilation error, you may want to save
> just the part that contains the compilation errors.

I like the idea of a separate "deal with attachment" buffer that pops up
a list of the parts and lets you choose which one to save/delete, etc. 
I'm thinking of the PC-Pine interface (screen shots at
http://www.best.com/~mattdav/mime/).  Something bothers me about having
to click around in the article buffer.
 
> However, the user must (I think) be given some visual clue as to where
> each parts starts (and stops).  The buttons are too heavy, but can
> anyone come up with some other clue that would be less intrusive?

Something like an HTML <hr> would look nice.  Maybe Xemacs can do that
kind of thing.  For FSF Emacs, maybe just a single line in a different
background color.  On a terminal, just a "--------------------------"
might work.  This is the way Netscape splits up the parts visually, and
I've always liked it.

Re: No more buttons by default?

[Hrvoje Niksic]

François Pinard <pinard@IRO.UMontreal.CA> writes:

> There are always ways!  But saving an image found in article buffer
> is no different from saving an image found in an HTML page, and this
> is not something which has to be a bold part of the MIME article
> viewer.

Why not?  In the browsers I use, it is possible to save the image
without ever seeing the HTML source.

> > Or of hiding the image from the buffer?  Or of saving the textual types
> > that happen not to be attachments?
> 
> When using an HTML browser, do you ask for hiding images from the
> display?

Emacs is not an HTML browser.  The browsers I use handle inline images 
much better than XEmacs does, so yes, I do want to hide images.

> There is no such strong reason to do so.  Do you ask for saving substrings
> on the page?

Here you assume the equivalence of MIME and HTML, which I disagree
with.  "Saving substrings on the page" is not a meaningful request,
but "saving a MIME part is".  Sprinkle IMHO's where appropriate.

> If the "decent Summary-based viewing mode" was giving access to the
> intimate structure of the MIME message, it would still be a
> debugging tool.

I meant something like `C-d', but that worked better.  We've already
discussed that.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Your lucky number today is 29842924728.  Look for it everywhere.

Re: No more buttons by default?

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Why not?  In the browsers I use, it is possible to save the image
> without ever seeing the HTML source.

I think that should be possible in Gnus as well -- by, for instance,
placing point over the image and pressing `o', or by using the pop-up
menu over the image.

> Emacs is not an HTML browser.

Well, if you have w3 installed, it is.

> The browsers I use handle inline images much better than XEmacs
> does, so yes, I do want to hide images.

Hidden images (as all other hidden parts) are still buttonized.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen