From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/24915 Path: main.gmane.org!not-for-mail From: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai =?iso-8859-1?q?Gro=DFjohann?=) Newsgroups: gmane.emacs.gnus.general Subject: Re: C-d displays duplicated parts Date: 27 Aug 1999 23:51:47 +0200 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1035162398 11307 80.91.224.250 (21 Oct 2002 01:06:38 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 01:06:38 +0000 (UTC) Return-Path: Original-Received: from bart.math.uh.edu (bart.math.uh.edu [129.7.128.48]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id RAA15403 for ; Fri, 27 Aug 1999 17:53:26 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by bart.math.uh.edu (8.9.1/8.9.1) with ESMTP id QAB24638; Fri, 27 Aug 1999 16:52:47 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 27 Aug 1999 16:53:23 -0500 (CDT) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id QAA15513 for ; Fri, 27 Aug 1999 16:53:13 -0500 (CDT) Original-Received: from waldorf.cs.uni-dortmund.de (waldorf.cs.uni-dortmund.de [129.217.4.42]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id RAA15346 for ; Fri, 27 Aug 1999 17:52:20 -0400 (EDT) Original-Received: from petty.cs.uni-dortmund.de (petty.cs.uni-dortmund.de [129.217.20.161]) by waldorf.cs.uni-dortmund.de with ESMTP id XAA06211 for ; Fri, 27 Aug 1999 23:51:49 +0200 (MES) Original-Received: (grossjoh@localhost) by petty.cs.uni-dortmund.de id XAA17326; Fri, 27 Aug 1999 23:51:48 +0200 (MET DST) Original-To: ding@gnus.org In-Reply-To: =?iso-8859-1?q?Fran=E7ois?= Pinard's message of "27 Aug 1999 17:29:12 -0400" Original-Lines: 53 User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:24915 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:24915 François Pinard writes: > This was a long time ago, I might not remember everything clearly. > I think the choice was between showing only the line, and > forcing the user to do another `C-d' to _enter_ it, or trying to > immediately serve him, and simulate a recursive `C-d' right away, > rather seamlessly integrated with the rest. But then, if the quoted > message happens to be a complex one, we need some way, at the > dissection level, to discriminate the passage from one message into > another, so the quoted message is first announced, then > sub-analysed. So, you see, it is not fully seamless. It should not > be. I must admit that I still don't understand why you need to introduce more parts. Let's say you have a multipart message, and the first part is message/rfc822 and the second is an image. Then nndoc will display the following structure: * |\ | * message/rfc822 | \ | * text/plain \ * image/gif This looks like three parts, but the message just contains two. And in what way is the node labeled text/plain necessary? Why can't nndoc just show the contents of the text/plain thing in the message/rfc822 node? If you copy this message and leave it exactly as is, except that you replace the message/rfc822 content type with application/octet-stream, say, then you will get the following tree: * |\ | * application/octet-stream | \ * image/gif Just changing the content-type can't make a node disappear, can it? If nndoc is meant to accurately represent the MIME structure, then I feel the above is suboptimal, I'm afraid. Probably I'm overlooking something here, though, showing that I fundamentally don't grok MIME. kai -- I like BOTH kinds of music.