Bug in deleting attachments

Bug in deleting attachments

[Karl Pflästerer]

Hi,
today I tried to delete an attachment and always got the annoying error
message: `This function is not implemented' (btw I find it misleading
because the function is indeed implemented).

I searched for the reason and found in `gnus-mime-delete-part' the
following code:

      (if (mm-multiple-handles gnus-article-mime-handles)
	  (error "This function is not implemented"))

I looked further and saw that definition of `mm-multiple-handles'

(defun mm-multiple-handles (handles)
  (and (listp handles)
       (> (length handles) 1)
       (or (listp (car handles))
	   (stringp (car handles)))))


The value of `gnus-article-mime-handles' in that case was:

("multipart/mixed" (#<buffer " *mm*<2>"> ("text/html" (charset .
"us-ascii")) 7bit (lambda nil (let (buffer-read-only) (delete-region
#<marker at 190 in *Article nnml+private:mail.other2004-02* 0x11b46f3c>
#<marker at 1206 in *Article nnml+private:mail.other2004-02*
0x11b46f54>))) nil nil nil nil) (#<buffer " *mm*<3>">
("application/x-zip-compressed" (name . "Raging Cajun.zip")) base64 nil
("inline" (filename . "Raging Cajun.zip")) nil nil nil)))


It was in a nnml group (which supports article editing) and the
application of mm-multiple-handles on that value gives t which returns
that error message (which is that just wrong here).

I changed the definition of `mm-multiple-handles' so that nil was
returned and the function `gnus-mime-delete-part' ran without problem.

I'm not sure at the moment what the exact reason of the bug is (I don't
know what `mm-multiple-handles' is exactly testing).  Can anyone shed
some light on that?


   KP

-- 
      And has thou slain the Jabberwock?
          Come to my arms, my beamish boy!
      O frabjous day!  Callooh!  Callay!'
          He chortled in his joy.   "Lewis Carroll" "Jabberwocky"

Re: Bug in deleting attachments

[Reiner Steib]

On Tue, Mar 02 2004, Karl Pflästerer wrote:

> today I tried to delete an attachment and always got the annoying error
> message: `This function is not implemented' (btw I find it misleading
> because the function is indeed implemented).
>
> I searched for the reason and found in `gnus-mime-delete-part' the
> following code:
>
>       (if (mm-multiple-handles gnus-article-mime-handles)
> 	  (error "This function is not implemented"))
[...]
> I changed the definition of `mm-multiple-handles' so that nil was
> returned and the function `gnus-mime-delete-part' ran without problem.
>
> I'm not sure at the moment what the exact reason of the bug is (I don't
> know what `mm-multiple-handles' is exactly testing).  Can anyone shed
> some light on that?

First, I have to admit that the code of `gnus-mime-delete-part' is
more or less copied from `gnus-mime-save-part-and-strip' (see the
FIXME).  In `gnus-mime-save-part-and-strip' ShengHuo added this check
deliberately:

,----[ <news:2n664zyl41.fsf@zsh.cs.rochester.edu> ]
| From: ShengHuo ZHU <zsh@cs.rochester.edu>
| Subject: Re: remove attachments
| Newsgroups: gnu.emacs.gnus
| Date: Thu, 14 Feb 2002 13:27:42 -0500
| Message-ID: <2n664zyl41.fsf@zsh.cs.rochester.edu>
| 
| Reiner Steib <4uce.02.r.steib@gmx.net> writes:
| [...]
| > Is it possible to strip a part that's inside a forwarded messsage
| > (Content-Type: message/rfc822)? I'd like to strip the
| > `application/msword' part from the following message (I get
| > `gnus-mime-save-part-and-strip: This function is not implemented'):
| 
| I disabled this feature on messages with complicated MIME structures
| because of some difficulties, such as locating the part, PGP or S/MIME
| stuff, etc.  Anyway, you can always edit the message manually if the
| back end supports it.
`----

But maybe we can change the error into a query like "Deleting parts in
complicated MIME structures might not work.  Are you sure?"?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Bug in deleting attachments

[Karl Pflästerer]

On  2 Mar 2004, Reiner Steib <- 4.uce.03.r.s@nurfuerspam.de wrote:

> First, I have to admit that the code of `gnus-mime-delete-part' is
> more or less copied from `gnus-mime-save-part-and-strip' (see the
> FIXME).  In `gnus-mime-save-part-and-strip' ShengHuo added this check
> deliberately:

Maybe if someone has the time and the knowledge he could write one
function which incorporates the common code (maybe even
`gnus-mime-save-part-and-strip' could just call `gnus-mime-delete-part'
and do some additional work).

> ,----[ <news:2n664zyl41.fsf@zsh.cs.rochester.edu> ]
> | From: ShengHuo ZHU <zsh@cs.rochester.edu>
> | Subject: Re: remove attachments
> | Newsgroups: gnu.emacs.gnus
> | Date: Thu, 14 Feb 2002 13:27:42 -0500
> | Message-ID: <2n664zyl41.fsf@zsh.cs.rochester.edu>
> | 
> | Reiner Steib <4uce.02.r.steib@gmx.net> writes:
> | [...]
> | > Is it possible to strip a part that's inside a forwarded messsage
> | > (Content-Type: message/rfc822)? I'd like to strip the
> | > `application/msword' part from the following message (I get
> | > `gnus-mime-save-part-and-strip: This function is not implemented'):
> | 
> | I disabled this feature on messages with complicated MIME structures
> | because of some difficulties, such as locating the part, PGP or S/MIME
> | stuff, etc.  Anyway, you can always edit the message manually if the
> | back end supports it.
> `----

> But maybe we can change the error into a query like "Deleting parts in
> complicated MIME structures might not work.  Are you sure?"?

That would definitley be better; at the moment I feeled as Gnus wanted
to stultify me saying a function was not implemented which indeed
existed.

Perhaps ShengHuo could explain where the problems are and we could find
a solution.  Manually editing isn't a real alternative IMO (you
shouldn't have to be a hacker to be able to use Gnus).

 
   KP

-- 
And as in uffish thought he stood,
The Jabberwock, with eyes of flame,
Came whiffling through the tulgey wood,
And burbled as it came!                "Lewis Carroll" "Jabberwocky"

Re: Bug in deleting attachments

[Katsumi Yamaoka]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 2923 bytes --]

>>>>> In <m3ishnks8m.fsf@hamster.pflaesterer.de>
>>>>>	sigurd@12move.de (Karl Pfl^[.A^[Ndsterer) wrote:

> I looked further and saw that definition of `mm-multiple-handles'

> (defun mm-multiple-handles (handles)
>   (and (listp handles)
>        (> (length handles) 1)
>        (or (listp (car handles))
> 	   (stringp (car handles)))))

I changed it to be used by the mm-w3m-cid-retrieve-1 function so
that it detects multiple handles in the strict sense of the name:

2004-01-15  Katsumi Yamaoka  <yamaoka@jpl.org>

	* mm-decoce.el (mm-multiple-handles): Recognize a string as a mime
	handle, as well as a list.

;; Oops, there's a typo!

The function definition used to be:

(defun mm-multiple-handles (handles)
  (and (listp (car handles))
       (> (length handles) 1)))

> The value of `gnus-article-mime-handles' in that case was:

> ("multipart/mixed" (#<buffer " *mm*<2>"> ("text/html" (charset .
> "us-ascii")) 7bit (lambda nil (let (buffer-read-only) (delete-region
> #<marker at 190 in *Article nnml+private:mail.other2004-02* 0x11b46f3c>
> #<marker at 1206 in *Article nnml+private:mail.other2004-02*
0x11b46f54>))) nil nil nil nil) (#<buffer " *mm*<3>">
> ("application/x-zip-compressed" (name . "Raging Cajun.zip")) base64 nil
> ("inline" (filename . "Raging Cajun.zip")) nil nil nil)))

It is reasonable that the present mm-multiple-handles returns t
for that case, isn't it? :)

>>>>> In <v9n06zggbe.fsf@marauder.physik.uni-ulm.de>
>>>>>	Reiner Steib <4.uce.03.r.s@nurfuerspam.de> wrote:

> First, I have to admit that the code of `gnus-mime-delete-part' is
> more or less copied from `gnus-mime-save-part-and-strip' (see the
> FIXME).  In `gnus-mime-save-part-and-strip' ShengHuo added this check
> deliberately:

> ,----[ <news:2n664zyl41.fsf@zsh.cs.rochester.edu> ]
>| From: ShengHuo ZHU <zsh@cs.rochester.edu>
>| Subject: Re: remove attachments
>| Newsgroups: gnu.emacs.gnus
>| Date: Thu, 14 Feb 2002 13:27:42 -0500
>| Message-ID: <2n664zyl41.fsf@zsh.cs.rochester.edu>
>| 
>| Reiner Steib <4uce.02.r.steib@gmx.net> writes:
>| [...]
>|> Is it possible to strip a part that's inside a forwarded messsage
>|> (Content-Type: message/rfc822)? I'd like to strip the
>|> `application/msword' part from the following message (I get
>|> `gnus-mime-save-part-and-strip: This function is not implemented'):
>| 
>| I disabled this feature on messages with complicated MIME structures
>| because of some difficulties, such as locating the part, PGP or S/MIME
>| stuff, etc.  Anyway, you can always edit the message manually if the
>| back end supports it.
> `----

> But maybe we can change the error into a query like "Deleting parts in
> complicated MIME structures might not work.  Are you sure?"?

And we probably have to provide the new function for that
purpose like:

(defun mm-complicated-handles (handles)
  (and (listp (car handles))
       (> (length handles) 1)))
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: Bug in deleting attachments

[Karl Pflästerer]

On  3 Mar 2004, Katsumi Yamaoka <- yamaoka@jpl.org wrote:

>>>>>> In <m3ishnks8m.fsf@hamster.pflaesterer.de>
>>>>>>	sigurd@12move.de (Karl Pflästerer) wrote:

>> The value of `gnus-article-mime-handles' in that case was:

>> ("multipart/mixed" (#<buffer " *mm*<2>"> ("text/html" (charset .
>> "us-ascii")) 7bit (lambda nil (let (buffer-read-only) (delete-region
>> #<marker at 190 in *Article nnml+private:mail.other2004-02* 0x11b46f3c>
>> #<marker at 1206 in *Article nnml+private:mail.other2004-02*
> 0x11b46f54>))) nil nil nil nil) (#<buffer " *mm*<3>">
>> ("application/x-zip-compressed" (name . "Raging Cajun.zip")) base64 nil
>> ("inline" (filename . "Raging Cajun.zip")) nil nil nil)))

> It is reasonable that the present mm-multiple-handles returns t
> for that case, isn't it? :)

Now that I know the reason for that test: yes (there's no docstring and
the name doesn't indicate IMO that too complicated mime buffers result
in t as return value (and to regard every buffer with a listlen > 1 as
complicated seems not very reasonable to me; the e-mail in question had
two parts: a html part and the zip attachment)).

I was brave; changed the return value to t and let the function run; it
worked like a charm.

Maybe we should look closer at it; I see no sense in a function which
should delete attachments which barfs if you have two mime parts in an
e-mail.


   KP

-- 
   Mary had a little lambda,
   Its syntax white as snow,
   And every program Mary wrote,
   She wrote in Lisp, you know.

Re: Bug in deleting attachments

[Stephen Berman]

On Wed, 03 Mar 2004 01:54:25 +0100 sigurd@12move.de (Karl Pflästerer) wrote:

> On  3 Mar 2004, Katsumi Yamaoka <- yamaoka@jpl.org wrote:
>
>>>>>>> In <m3ishnks8m.fsf@hamster.pflaesterer.de>
>>>>>>>	sigurd@12move.de (Karl Pflästerer) wrote:
>
>>> The value of `gnus-article-mime-handles' in that case was:
>
>>> ("multipart/mixed" (#<buffer " *mm*<2>"> ("text/html" (charset .
>>> "us-ascii")) 7bit (lambda nil (let (buffer-read-only) (delete-region
>>> #<marker at 190 in *Article nnml+private:mail.other2004-02* 0x11b46f3c>
>>> #<marker at 1206 in *Article nnml+private:mail.other2004-02*
>> 0x11b46f54>))) nil nil nil nil) (#<buffer " *mm*<3>">
>>> ("application/x-zip-compressed" (name . "Raging Cajun.zip")) base64 nil
>>> ("inline" (filename . "Raging Cajun.zip")) nil nil nil)))
>
>> It is reasonable that the present mm-multiple-handles returns t
>> for that case, isn't it? :)
>
> Now that I know the reason for that test: yes (there's no docstring and
> the name doesn't indicate IMO that too complicated mime buffers result
> in t as return value (and to regard every buffer with a listlen > 1 as
> complicated seems not very reasonable to me; the e-mail in question had
> two parts: a html part and the zip attachment)).
>
> I was brave; changed the return value to t and let the function run; it
> worked like a charm.
>
> Maybe we should look closer at it; I see no sense in a function which
> should delete attachments which barfs if you have two mime parts in an
> e-mail.

Has anyone fixed this yet and if so can it be checked in?  I got bit
by this yesterday when I updated Gnus from 5.10.6 to CVS.  I found the
change in mm-multiple-handles and was about to send off a bug report
when I saw this thread.

--Steve Berman

Re: Bug in deleting attachments

[Katsumi Yamaoka]

>>>>> In <v9n06zggbe.fsf@marauder.physik.uni-ulm.de>
>>>>>	Reiner Steib <4.uce.03.r.s@nurfuerspam.de> wrote:

> But maybe we can change the error into a query like "Deleting parts in
> complicated MIME structures might not work.  Are you sure?"?

>>>>> In <m3ad2trm5r.fsf@feldmann.local.home>
>>>>>	Stephen Berman <Stephen.Berman@gmx.net> wrote:

> Has anyone fixed this yet and if so can it be checked in?  I got bit
> by this yesterday when I updated Gnus from 5.10.6 to CVS.  I found the
> change in mm-multiple-handles and was about to send off a bug report
> when I saw this thread.

I've modified those functions so that they may ask whether to
perform things truly instead of signaling an error.  Now they
prompt user as follows:

Deleting parts may malfunction or destroy the article; continue?

However, it is the second best.  If there is a means to detect
complicated and delicate mime structure correctly, we will have
to forbid deletion after all.
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: Bug in deleting attachments

[Stephen Berman]

On Tue, 09 Mar 2004 17:37:27 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote:

>>>>>> In <v9n06zggbe.fsf@marauder.physik.uni-ulm.de>
>>>>>>	Reiner Steib <4.uce.03.r.s@nurfuerspam.de> wrote:
>
>> But maybe we can change the error into a query like "Deleting parts in
>> complicated MIME structures might not work.  Are you sure?"?
>
>>>>>> In <m3ad2trm5r.fsf@feldmann.local.home>
>>>>>>	Stephen Berman <Stephen.Berman@gmx.net> wrote:
>
>> Has anyone fixed this yet and if so can it be checked in?  I got bit
>> by this yesterday when I updated Gnus from 5.10.6 to CVS.  I found the
>> change in mm-multiple-handles and was about to send off a bug report
>> when I saw this thread.
>
> I've modified those functions so that they may ask whether to
> perform things truly instead of signaling an error.  Now they
> prompt user as follows:
>
> Deleting parts may malfunction or destroy the article; continue?
>
> However, it is the second best.  If there is a means to detect
> complicated and delicate mime structure correctly, we will have
> to forbid deletion after all.

I tried your new changes on a simple text mail with a single
attachment and after answering yes, the attachment was deleted.  Then
I tried to delete an attachment in a more complicated email with four
MIME parts: 1. text/plain, 2. message/rfc822, 3. text/plain,
4. application/x-zip-compressed -- the latter is the part I tried to
delete (parts 2.-4. comprise a forwarded email within the email).
After answering yes to the question, I got a wrong-type-argument error
(anonymized backtrace below).  Then I found myself in an article edit
buffer, with the entire contents of the article (not just the
attachment) deleted.  I undid the deletion, typed `C-c C-c' and got
the message "gnus-article-edit-done: Symbol's function definition is
void: nil".  Then I tried to save the article to a file, and got the
message "gnus-article-save: Wrong type argument: stringp, nil".  At
this point I just removed the read mark from the article and quit the
group.

With Gnus 5.10.6, I also couldn't deleted the attachment of the
complicated email, but got the "This function is not implemented"
error message.

--Steve Berman

Debugger entered--Lisp error: (wrong-type-argument stringp (#("multipart/mixed" 0 15 (start nil from "somebody@somewhere.com" buffer #<buffer  *mm*> boundary "0-619311294-1078790361=:27352")) (#<buffer  *mm*<2>> ("text/plain" (charset . "us-ascii")) nil (lambda nil (let (buffer-read-only) (delete-region #<marker at 1 in *Article*> #<marker at 1 in *Article*>))) ("inline") nil nil "") (#<buffer  *mm*<3>> ("message/rfc822") nil (lambda nil (let (buffer-read-only) (if (fboundp (quote remove-specifier)) (mapcar (lambda (prop) (remove-specifier (face-property (quote default) prop) (current-buffer))) (quote (background background-pixmap foreground)))) (delete-region #<marker at 1 in *Article*> #<marker at 1 in *Article*>))) nil nil nil nil)))
  insert-buffer-substring((#("multipart/mixed" 0 15 (start nil from "somebody@somewhere.com" buffer #<buffer  *mm*> boundary "0-619311294-1078790361=:27352")) (#<buffer  *mm*<2>> ("text/plain" ...) nil (lambda nil ...) ("inline") nil nil "") (#<buffer  *mm*<3>> ("message/rfc822") nil (lambda nil ...) nil nil nil nil)))
  mm-insert-part(((#("multipart/mixed" 0 15 ...) (#<buffer  *mm*<2>> ... nil ... ... nil nil "") (#<buffer  *mm*<3>> ... nil ... nil nil nil nil)) (#("multipart/mixed" 0 15 ...) (#<buffer  *mm*<6>> ... nil ... ... nil nil "") (#<buffer  *mm*<7>> ... nil nil ... "Deleted attachment (590903 bytes)" nil nil))))
  mml-insert-mime(((#("multipart/mixed" 0 15 ...) (#<buffer  *mm*<2>> ... nil ... ... nil nil "") (#<buffer  *mm*<3>> ... nil ... nil nil nil nil)) (#("multipart/mixed" 0 15 ...) (#<buffer  *mm*<6>> ... nil ... ... nil nil "") (#<buffer  *mm*<7>> ... nil nil ... "Deleted attachment (590903 bytes)" nil nil))) t)
  mime-to-mml(((#("multipart/mixed" 0 15 ...) (#<buffer  *mm*<2>> ... nil ... ... nil nil "") (#<buffer  *mm*<3>> ... nil ... nil nil nil nil)) (#("multipart/mixed" 0 15 ...) (#<buffer  *mm*<6>> ... nil ... ... nil nil "") (#<buffer  *mm*<7>> ... nil nil ... "Deleted attachment (590903 bytes)" nil nil))))
  (let ((mail-parse-charset ...) (mail-parse-ignored-charsets ...) (mbl mml-buffer-list)) (setq mml-buffer-list nil) (insert-buffer gnus-original-article-buffer) (mime-to-mml (quote ...)) (setq gnus-article-mime-handles nil) (let (...) (setq mml-buffer-list mbl) (set ... mbl1)) (gnus-make-local-hook (quote kill-buffer-hook)) (add-hook (quote kill-buffer-hook) (quote mml-destroy-buffers) t t))
  (lambda nil (erase-buffer) (let (... ... ...) (setq mml-buffer-list nil) (insert-buffer gnus-original-article-buffer) (mime-to-mml ...) (setq gnus-article-mime-handles nil) (let ... ... ...) (gnus-make-local-hook ...) (add-hook ... ... t t)))()
  gnus-article-edit-article((lambda nil (erase-buffer) (let (... ... ...) (setq mml-buffer-list nil) (insert-buffer gnus-original-article-buffer) (mime-to-mml ...) (setq gnus-article-mime-handles nil) (let ... ... ...) (gnus-make-local-hook ...) (add-hook ... ... t t))) (lambda (no-highlight) (let (... ... ... ...) (mml-to-mime) (mml-destroy-buffers) (remove-hook ... ... t) (kill-local-variable ...)) (gnus-summary-edit-article-done "" nil #<buffer *Summary nnfolder+private:unsorted*> no-highlight)))
  gnus-mime-delete-part()
  call-interactively(gnus-mime-delete-part)

Re: Bug in deleting attachments

[Katsumi Yamaoka]

>>>>> In <m3n06puiey.fsf@feldmann.germanistik.ruhr-uni-bochum.de>
>>>>>	Stephen Berman <Stephen.Berman@gmx.net> wrote:

> I tried your new changes on a simple text mail with a single
> attachment and after answering yes, the attachment was deleted.  Then
> I tried to delete an attachment in a more complicated email with four
> MIME parts: 1. text/plain, 2. message/rfc822, 3. text/plain,
> 4. application/x-zip-compressed -- the latter is the part I tried to
> delete (parts 2.-4. comprise a forwarded email within the email).
> After answering yes to the question, I got a wrong-type-argument error
> (anonymized backtrace below).  Then I found myself in an article edit
> buffer, with the entire contents of the article (not just the
> attachment) deleted.  I undid the deletion, typed `C-c C-c' and got
> the message "gnus-article-edit-done: Symbol's function definition is
> void: nil".  Then I tried to save the article to a file, and got the
> message "gnus-article-save: Wrong type argument: stringp, nil".  At
> this point I just removed the read mark from the article and quit the
> group.

> With Gnus 5.10.6, I also couldn't deleted the attachment of the
> complicated email, but got the "This function is not implemented"
> error message.

Ah, I see.  I revived former mm-multiple-handles function as
mm-complicated-handles.  You probably won't be satisfied, though.
We need to improve MML seriously...
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: Bug in deleting attachments

[Stephen Berman]

On Wed, 10 Mar 2004 20:52:45 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote:

>>>>>> In <m3n06puiey.fsf@feldmann.germanistik.ruhr-uni-bochum.de>
>>>>>>	Stephen Berman <Stephen.Berman@gmx.net> wrote:
[...]
>> With Gnus 5.10.6, I also couldn't deleted the attachment of the
>> complicated email, but got the "This function is not implemented"
>> error message.
>
> Ah, I see.  I revived former mm-multiple-handles function as
> mm-complicated-handles.  You probably won't be satisfied, though.
> We need to improve MML seriously...

Yes, that would be good -- if it's possible.  Earlier in this thread
the following exchange was cited:

>|> Is it possible to strip a part that's inside a forwarded messsage
>|> (Content-Type: message/rfc822)? I'd like to strip the
>|> `application/msword' part from the following message (I get
>|> `gnus-mime-save-part-and-strip: This function is not implemented'):
>| 
>| I disabled this feature on messages with complicated MIME structures
>| because of some difficulties, such as locating the part, PGP or S/MIME
>| stuff, etc.  Anyway, you can always edit the message manually if the
>| back end supports it.
> `----

Was the feature disabled because it didn't work at all or not well
enough?  Are the difficulties mentioned fundamental issues with MIME
or rather their proper implementation within Gnus?

--Steve Berman

Re: Bug in deleting attachments

[Katsumi Yamaoka]

>>>>> In <m3ishcvp8r.fsf@feldmann.germanistik.ruhr-uni-bochum.de>
>>>>>	Stephen Berman <Stephen.Berman@gmx.net> wrote:

[...]

>>|> Is it possible to strip a part that's inside a forwarded messsage
>>|> (Content-Type: message/rfc822)? I'd like to strip the
>>|> `application/msword' part from the following message (I get
>>|> `gnus-mime-save-part-and-strip: This function is not implemented'):
>>| 
>>| I disabled this feature on messages with complicated MIME structures
>>| because of some difficulties, such as locating the part, PGP or S/MIME
>>| stuff, etc.  Anyway, you can always edit the message manually if the
>>| back end supports it.
>> `----

> Was the feature disabled because it didn't work at all or not well
> enough?

I think so.

> Are the difficulties mentioned fundamental issues with MIME or
> rather their proper implementation within Gnus?

The structure of MIME can be complicated without limit and
needs to be processed recursively and also reversibly.  Gnus as
a good MIME composer is peerless in the world.  However, more
advanced technology is required there and we haven't completed
it yet.  The present MIME handling of Gnus may have lapsed into
the dead end or our efforts may only be insufficient.  Anyway,
I don't grasp them deeply, I need to stack study more.
-- 
Katsumi Yamaoka <yamaoka@jpl.org>
;; Supposing my writing is strange, that is because I'm not a
;; good writer except Japanese.  Malice is not in me so don't
;; shoot me. :)

Re: Bug in deleting attachments

[Katsumi Yamaoka]

>>>>> In <b9y1xo0qngv.fsf@jpl.org> Katsumi Yamaoka wrote:

> Anyway, I don't grasp them deeply, I need to stack study more.

I grasped all.  Now I can say that it is impossible to delete a
part in the article which has a complicated MIME structure.  In
the article buffer, the original complicated MIME structure is
flattened in order that a user may able to access into every
parts conveniently.  However, there is no information for
restoring the original complicated MIME structure.  To enable
it, we need to change greatly the MIME handling in the article
buffer.

I will highly appreciate someone thinking out a counterargument,
that is, a good idea.
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: Bug in deleting attachments

[Stephen Berman]

On Thu, 11 Mar 2004 20:30:14 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote:

>>>>>> In <b9y1xo0qngv.fsf@jpl.org> Katsumi Yamaoka wrote:
>
>> Anyway, I don't grasp them deeply, I need to stack study more.
>
> I grasped all.  Now I can say that it is impossible to delete a
> part in the article which has a complicated MIME structure.  In
> the article buffer, the original complicated MIME structure is
> flattened in order that a user may able to access into every
> parts conveniently.  However, there is no information for
> restoring the original complicated MIME structure.  To enable
> it, we need to change greatly the MIME handling in the article
> buffer.

Is it always necessary to be able to restore the MIME structure?  Can
it cause serious problems to allow users to operate irreversibly on
the flattened structure?  When I decide I want to strip and save or
delete an attachment, I'm quite certain I don't want to put it back.
Or do you mean something else by "restoring the original complicated
MIME structure"?  If so, would it still be possible to allow users, at
their own risk, to strip and save or delete parts from complicated
MIME structures, as is now done with simple MIME structures?

--Steve Berman

Re: Bug in deleting attachments

[Katsumi Yamaoka]

>>>>> In <m3smgezahl.fsf@feldmann.germanistik.ruhr-uni-bochum.de>
>>>>>	Stephen Berman <Stephen.Berman@gmx.net> wrote:

> On Thu, 11 Mar 2004 20:30:14 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote:

>> I grasped all.  Now I can say that it is impossible to delete a
>> part in the article which has a complicated MIME structure.  In
>> the article buffer, the original complicated MIME structure is
>> flattened in order that a user may able to access into every
>> parts conveniently.  However, there is no information for
>> restoring the original complicated MIME structure.  To enable
>> it, we need to change greatly the MIME handling in the article
>> buffer.

> Is it always necessary to be able to restore the MIME structure?  Can
> it cause serious problems to allow users to operate irreversibly on
> the flattened structure?  When I decide I want to strip and save or
> delete an attachment, I'm quite certain I don't want to put it back.
> Or do you mean something else by "restoring the original complicated
> MIME structure"?  If so, would it still be possible to allow users, at
> their own risk, to strip and save or delete parts from complicated
> MIME structures, as is now done with simple MIME structures?

Well, is it possible to explain in my poor English? :)

Imagine there is a forwarded message including two attachments.
It will be displayed in the article buffer as follows:

--8<---------------cut here---------------start------------->8---
HEADER

[1. text/plain]

Hi,

[2. message/rfc822]

HEADER

[3. text/plain]

Dear sir,

[4. application/octet-stream; attachment-1]

[5. application/octet-stream; attachment-2]
--8<---------------cut here---------------end--------------->8---

(Type the `M-t' key in the summary buffer to show the buttons.)

You can save either the whole forwarded message or only the
attachment-1 into a local file by typing the `o' key at the
button-2 or button-4 respectively.  That is convenient.  The
reason you can do it is because Gnus has prepared raw contents
on the hidden buffers for all the buttons.  It means both the
buffer for the button-2 and the buffer for the button-4 contain
the same attachment-1.

Even if you can delete the attachment-1 by typing the `d' key at
the button-4, the same attachment-1 is still in the hidden
buffer for the button-2.  And there is no way to delete it.
This is the reason why deleting parts is impossible.

Another difficulty is in restoring the MIME structure.  Although
I wrote that the forwarded message contains two attachments, the
attachment-2 may not belong to the forwarded message.  Who knows
if it doesn't belong to the main message?  That is, there is no
information for restoring them correctly, so we can't resave the
modified message into a file.  It may not need to be completely
correct, though.

The present MIME handling in the article buffer is pretty good.
However, in fact it is incomplete.
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: Bug in deleting attachments

[Stephen Berman]

On Fri, 12 Mar 2004 20:19:32 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote:
>
> You can save either the whole forwarded message or only the
> attachment-1 into a local file by typing the `o' key at the
> button-2 or button-4 respectively.  That is convenient.  The
> reason you can do it is because Gnus has prepared raw contents
> on the hidden buffers for all the buttons.  It means both the
> buffer for the button-2 and the buffer for the button-4 contain
> the same attachment-1.
>
> Even if you can delete the attachment-1 by typing the `d' key at
> the button-4, the same attachment-1 is still in the hidden
> buffer for the button-2.  And there is no way to delete it.
> This is the reason why deleting parts is impossible.

I see now, thanks.  I wonder if it would be worthwhile to implement a
function to split a message up into its constituent MIME parts without
overlap in the hidden buffers, at the cost, of course, of permanently
destroying the MIME structure, making restoration impossible.  (Maybe
this would be no different than just editing the message by hand, but
more convenient for things like deleting an attachment.)

> Another difficulty is in restoring the MIME structure.  Although
> I wrote that the forwarded message contains two attachments, the
> attachment-2 may not belong to the forwarded message.  Who knows
> if it doesn't belong to the main message?  That is, there is no
> information for restoring them correctly, so we can't resave the
> modified message into a file.  It may not need to be completely
> correct, though.

Maybe this is the trade-off users would have to accept if they allow
the MIME structure to be destroyed (by calling a function like the one
I speculated about above).

--Steve Berman

Re: Bug in deleting attachments

[Kai Grossjohann]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Another difficulty is in restoring the MIME structure.  Although
> I wrote that the forwarded message contains two attachments, the
> attachment-2 may not belong to the forwarded message.  Who knows
> if it doesn't belong to the main message?  That is, there is no
> information for restoring them correctly, so we can't resave the
> modified message into a file.  It may not need to be completely
> correct, though.

I wonder if it would work to allow another article buffer
presentation, where Gnus shows buttons for the top level of the MIME
structure only.  Invoking a non-leaf button would then show another
buffer with the next level in it.  Then users can navigate the tree to
the right node, delete something, then Gnus can recursively rebuild
the structure again.

Or maybe the gnus-summary-enter-digest-group code could be enhanced to
do such editing?  That would be way cool.

(In fact, I've been wanting to edit digests for some time, now.  I
wanted to mark some articles and compose them into a digest, which is
written as a new article to the same group.  Then, later, I might wish
to add another article to that digest.)

Kai

Re: Bug in deleting attachments

[Katsumi Yamaoka]

>>>>> In <87llm5ufl4.fsf@emptyhost.emptydomain.de>
>>>>>	Kai Grossjohann <kai@emptydomain.de> wrote:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> Another difficulty is in restoring the MIME structure.

[...]

> I wonder if it would work to allow another article buffer
> presentation, where Gnus shows buttons for the top level of the MIME
> structure only.  Invoking a non-leaf button would then show another
> buffer with the next level in it.  Then users can navigate the tree to
> the right node, delete something, then Gnus can recursively rebuild
> the structure again.

Let me introduce the way of SEMI MIME-View which is used by
Wanderlust, T-gnus, etc.  Although there is no convenient
function to delete a part in the article (and to resave it into
a file) like Gnus.  It keeps the hierarchical MIME structure
completely in the article presentation buffer.  For example:

--8<---------------cut here---------------start------------->8---
HEADER

[1  <text/plain (7bit)>]
Hi,

[2  <message/rfc822 (7bit)>]
HEADER

[2.1.1  <text/plain (7bit)>]
Dear sir,

[2.1.2  attachment-1 <application/octet-stream (base64)>]

[2.1.3  attachment-2 <application/octet-stream (base64)>]
--8<---------------cut here---------------end--------------->8---

The way of numbering buttons is similar to the way CVS manages
branches and revisions.

> Or maybe the gnus-summary-enter-digest-group code could be enhanced to
> do such editing?  That would be way cool.

We may also be able to achieve that.  The point will be to make
an interface that users can understand easily, like MML.  On the
other hand, I fear that the code may be very complicated.

> (In fact, I've been wanting to edit digests for some time, now.  I
> wanted to mark some articles and compose them into a digest, which is
> written as a new article to the same group.  Then, later, I might wish
> to add another article to that digest.)

Hm, there may be only the way of editing the digest by MML and
sending it to yourself...
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: Bug in deleting attachments

[Katsumi Yamaoka]

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

Hi,


[-- Attachment #2.1: Type: text/plain, Size: 592 bytes --]

I tried to recompute the hierarchical MIME structure in the
article buffer, and made Gnus show it in MIME buttons.  You
might ask whether it enables deletion of MIME parts in the near
future.  However, I'm sorry for not being sure of it for the
present.

To show the hierarchy numbers in MIME buttons, specify the
gnus-mime-buttons-show-hierarchy variable to nil and type the
`M-t' key in the summary buffer.  Of course you also need to
upgrade Gnus in advance.

Currently the gnus-article-mime-hierarchy variable holds the
hierarchical MIME structure in the article buffer.  It looks
like:


[-- Attachment #2.2: Type: text/plain, Size: 57 bytes --]

(((1) H) ((2 1) H) ((2 2) H) ((2 3) H) ((3) H) ((4) H))


[-- Attachment #2.3: Type: text/plain, Size: 148 bytes --]

It is possible to let it contain MIME handles shown above as
`H's, however now it doesn't do so.  See the
gnus-mime-accumulate-hierarchy function.


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

Anyhow, I found again it is very hard to realize the plan.  I'm
afraid we might be unable to get out of the dead end...

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

-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: Bug in deleting attachments

[Katsumi Yamaoka]

>>>>> In <b9y65d1dq6t.fsf@jpl.org> Katsumi Yamaoka wrote:

> To show the hierarchy numbers in MIME buttons, specify the
> gnus-mime-buttons-show-hierarchy variable to nil and...

Ouch!  That is `gnus-mime-recompute-hierarchical-structure'.
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: Bug in deleting attachments

[Katsumi Yamaoka]

Oops.  How careless of me.

>>>>>> In <b9y65d1dq6t.fsf@jpl.org> Katsumi Yamaoka wrote:

>> To show the hierarchy numbers in MIME buttons, specify the
>> gnus-mime-buttons-show-hierarchy variable to nil and...

> Ouch!  That is `gnus-mime-recompute-hierarchical-structure'.

Set it as t, not nil.  Sorry.
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: Bug in deleting attachments

[Katsumi Yamaoka]

>>>>> In <b9y65d1dq6t.fsf@jpl.org> Katsumi Yamaoka wrote:

> I tried to recompute the hierarchical MIME structure in the
> article buffer, and made Gnus show it in MIME buttons.  You
> might ask whether it enables deletion of MIME parts in the near
> future.  However, I'm sorry for not being sure of it for the
> present.

I think there is not much likelihood that the approach will be
successful, so I withdrew those changes.  Sorry.
-- 
Katsumi Yamaoka <yamaoka@jpl.org>