gnus-summary-enter-digest-group

gnus-summary-enter-digest-group

[Jack Vinson]

When I use gnus-summary-enter-digest-group on a forwarded message, I get
something different than what I expect to get.  For example, a message from
a friend has 1) a text part and 2) the forward.  When I Ctrl-D on the
message, it is displayed as follows (after unhiding the thread):

   [ 103: *Marci Cohen        ] <* mixed> Fwd: this is the message
       [   2: *Marci Cohen        ] <1 text>
       [  88: *Marci Cohen        ] <2 rfc822>
           [  67: *Moshe              ] <2 text> this is the message
	   
What I would expect is something like
       [   2: *Marci Cohen        ] <1 text>
       [  67: *Moshe              ] <2 text> this is the message

which represents the text from Marci and the original message from Moshe. 

I understand that the gnus-summary-enter-digest-group function has to deal
with all sorts of messages.  Could this be done better?  What ends up
happening is that I can keep hitting running
gnus-summary-enter-digest-group on the subsequent message and get
infinitely nesting *Summary* buffers that all look the same.

This is in pgnus 0.72, although I am fairly sure I saw it in 0.75.

-- 
Jack Vinson <jvinson@chevax.ecs.umass.edu>    http://www.cis.upenn.edu/~vinson/
Zippy: TAILFINS!!  ...click...

Re: gnus-summary-enter-digest-group

[Lars Magne Ingebrigtsen]

Jack Vinson <jvinson@chevax.ecs.umass.edu> writes:

> When I use gnus-summary-enter-digest-group on a forwarded message, I get
> something different than what I expect to get.  For example, a message from
> a friend has 1) a text part and 2) the forward.  When I Ctrl-D on the
> message, it is displayed as follows (after unhiding the thread):
> 
>    [ 103: *Marci Cohen        ] <* mixed> Fwd: this is the message
>        [   2: *Marci Cohen        ] <1 text>
>        [  88: *Marci Cohen        ] <2 rfc822>
>            [  67: *Moshe              ] <2 text> this is the message
> 
> What I would expect is something like
>        [   2: *Marci Cohen        ] <1 text>
>        [  67: *Moshe              ] <2 text> this is the message

nndoc here displays a multipart message as a thread -- I find that
this models the structure of MIME messages in an enlightening manner.

And if you want to read a part, you just select it.

> I understand that the gnus-summary-enter-digest-group function has to deal
> with all sorts of messages.  Could this be done better?  What ends up
> happening is that I can keep hitting running
> gnus-summary-enter-digest-group on the subsequent message and get
> infinitely nesting *Summary* buffers that all look the same.

I hadn't considered that, but I think that sounds way neat.  :-)

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

Re: gnus-summary-enter-digest-group

[Kai.Grossjohann]

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

  > nndoc here displays a multipart message as a thread -- I find that
  > this models the structure of MIME messages in an enlightening manner.

The merit of the rfc822 parts is not obvious, though.  Selecting it
doesn't show the real forwarded message; for that one needs to select
the next (text/plain) part.

Forwarded messages will always be shown as one message/rfc822 part
containing a text/plain part, and users are always going to want to
look at the latter.  The naming suggests to look at the former,
though.

kai
-- 
I like _\bb_\bo_\bt_\bh kinds of music.

Re: gnus-summary-enter-digest-group

[Lars Magne Ingebrigtsen]

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

> Forwarded messages will always be shown as one message/rfc822 part
> containing a text/plain part, and users are always going to want to
> look at the latter.  The naming suggests to look at the former,
> though.

Well, nndoc does multiparts thusly:

   [  66: -> larsi@ifi.uio.no ] <* mixed> [Brian Gorka <gorkab@cyberpass.net>]
       [   2: -> larsi@ifi.uio.no ] <1 text>
       [  44: -> larsi@ifi.uio.no ] <2 rfc822>
           [  40: Brian Gorka         ] <2 text> S O m in a Summary Buffer
       [   4: -> larsi@ifi.uio.no ] <3 text>

The first article is the complete thing.  The second is the first text 
part.  The third is the complete rfc822 part (with the Mime headers,
which will usually just say something like "Content-Disposition:
inline").  The fourth is the contents of the rfc822 part.  The fifth
is the final text/plain part.

Seems logical to me.

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

Re: gnus-summary-enter-digest-group

[Per Abrahamsen]

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

> Seems logical to me.

It is logical, it is just not very intuitive.

Re: gnus-summary-enter-digest-group

[Kai.Grossjohann]

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

  > Seems logical to me.

I intuitively click on the `rfc822' part, expecting it to contain the
message.  But no, it contains nothing useful, and you have to click on
the text part right after it.

Like Per said, logical but not intuitive.  Hm.  Maybe the intuitive
people should just use `4 2 b' to display the message...

kai
-- 
I like _\bb_\bo_\bt_\bh kinds of music.

Re: gnus-summary-enter-digest-group

[Lars Magne Ingebrigtsen]

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

> Like Per said, logical but not intuitive.  Hm.  Maybe the intuitive
> people should just use `4 2 b' to display the message...

I think so.  But perhaps we have taken the two options to an extreme.
The nndoc view of MIME is totally pedantic, and displays absolutely
all information there is about a MIME multipart -- more information
that anybody wants.  The Gnus inline view of a MIME multipart goes
overboard the other way, trying to hide all MIME-ness from the viewer, 
and presenting a purdy, seamless whole.

I guess most other serious implementations that have been attempted
(say, TM and SEMI, which are the only other two serious
implementations I've seen (although my guess is that the VM
implementation is probably quite serious, but I haven't seen that (and
no, I don't think the Mozilla implementation is serious.  Or the MSIE
one))) have been somewhere in the middle of these two extremes, but
I'm quite comfortable with the current Gnus situation.

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

Re: gnus-summary-enter-digest-group

[Kai.Grossjohann]

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

  > I think so.  But perhaps we have taken the two options to an
  > extreme.  The nndoc view of MIME is totally pedantic, and displays
  > absolutely all information there is about a MIME multipart -- more
  > information that anybody wants.  The Gnus inline view of a MIME
  > multipart goes overboard the other way, trying to hide all
  > MIME-ness from the viewer, and presenting a purdy, seamless whole.

I think I can now explain my position much better.  Maybe my
understanding of multipart is wrong, but I thought that each part is
preceded by the delimiter and a few headers.  Thus, the number of
parts should be equal to the number of delimiters.

Now, look at the following excerpt from a mail:

,----- (quite a few headers elided)
| X-From-Line: vvv@vvv.vsu.ru Sun Feb 21 23:50:58 1999
| To: ding@gnus.org
| Subject: one more example of weird highlighting (colouring)
| MIME-Version: 1.0
| Content-Type: multipart/mixed; boundary="=-=-="
| From: Vladimir Volovich <vvv@vvv.vsu.ru>
| Date: 22 Feb 1999 01:45:47 +0300
| 
| This is a MIME multipart message.  If you are reading
| this, you shouldn't.
| 
| --=-=-=
| 
| Hi,
| 
| here is it (again, view via C-d):
| 
| 
| --=-=-=
| Content-Type: message/rfc822
| Content-Disposition: inline
| Content-Transfer-Encoding: quoted-printable
| 
| From: "Richard B. Johnson" <root@chaos.analogic.com>
| Date: Sun, 21 Feb 1999 16:28:30 -0500 (EST)
| Subject: Re: Routing Table (Feature)
| 
| On Sun, 21 Feb 1999 kuznet@ms2.inr.ac.ru wrote:
| 
| > Hello!
`-----

In the above, one sees two occurrences of "--=-=-=", thus, one would
expect two parts.  nndoc displays three parts, though!  The `here it
is again' part is a text/plain part, then there's a message/rfc822
part *and* a text/plain part for the stuff after the second
delimiter.  Why is that?  IMO there should only be a message/rfc822
part and nothing else.

I mean, it is nice that nndoc is very very pedantic.  But exactly the
pedanticness requirement would mean that it displayes two parts, not
three, right?

Maybe I'm misunderstanding something, here.  Please enlighten me.

kai
-- 
I like _\bb_\bo_\bt_\bh kinds of music.