Bug in "View as type"?

Bug in "View as type"?

[Reiner Steib]

Hi,

if I understand the code correctly, `gnus-mime-view-part-as-type'
(bound to `t' on MIME buttons) is supposed to offer the type by
calling `mm-default-file-encoding' in
`gnus-mime-view-part-as-type-internal'.  I.e. when the content type is
application/octet-stream and the file is in fact image/whatever or
application/pdf (some broken mailers do), the user should be offered
as more reasonable default.

But in fact this doesn't work (at least for me):

(get-text-property (point) 'gnus-data)
=> (#<buffer  *mm*<7>> ("application/octet-stream") base64 nil
    ("attachment" (filename . "cookies.txt")) nil nil nil)

(mm-handle-type ...)
=> ("application/octet-stream")

(mail-content-type-get ... 'name)
=> nil


The following seems to do better.  

The only use of `gnus-mime-view-part-as-type-internal' is in
`gnus-mime-view-part-as-type'.  Or can anyone imaging a situation
where the current implementation is preferable?

Do we have some shortcut for this?

  (cdr (assq 'name (cdr (mm-handle-disposition handle))))

--8<---------------cut here---------------start------------->8---
--- gnus-art.el	27 Sep 2005 17:50:05 +0200	7.128
+++ gnus-art.el	11 Oct 2005 22:59:23 +0200	
@@ -4317,9 +4317,9 @@
 
 (defun gnus-mime-view-part-as-type-internal ()
   (gnus-article-check-buffer)
-  (let* ((name (mail-content-type-get
-		(mm-handle-type (get-text-property (point) 'gnus-data))
-		'name))
+  (let* ((handle (get-text-property (point) 'gnus-data))
+	 (name (or (cdr (assq 'name (cdr (mm-handle-disposition handle))))
+		   (cdr (assq 'filename (cdr (mm-handle-disposition handle))))))
 	 (def-type (and name (mm-default-file-encoding name))))
     (and def-type (cons def-type 0))))
 
@@ -4328,10 +4328,12 @@
   (interactive)
   (unless mime-type
     (setq mime-type (completing-read
-		     "View as MIME type: "
+		     (format "View as MIME type (default %s): "
+			     (car (gnus-mime-view-part-as-type-internal)))
 		     (mapcar #'list (mailcap-mime-types))
 		     nil nil
-		     (gnus-mime-view-part-as-type-internal))))
+		     nil nil
+		     (car (gnus-mime-view-part-as-type-internal)))))
   (gnus-article-check-buffer)
   (let ((handle (get-text-property (point) 'gnus-data)))
     (when handle
--8<---------------cut here---------------end--------------->8---


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

Re: Bug in "View as type"?

[Adam Sjøgren]

On Tue, 11 Oct 2005 23:04:41 +0200, Reiner wrote:

[...]
> when the content type is application/octet-stream and the file is in
> fact image/whatever or application/pdf (some broken mailers do), the
> user should be offered as more reasonable default.

> But in fact this doesn't work (at least for me):

For what it is worth: This works for me. I just chose 'View as type'
on:

  [2. application/octet-stream; message.wav]...

And was prompted like this:

  View as MIME type: audio/x-wav

(Just a datapoint).


  Best regards,

-- 
 "I'm sorry I sound calm. I assure you that                   Adam Sjøgren
  I am hysterical."                                      asjo@koldfront.dk

Re: Bug in "View as type"?

[Reiner Steib]

On Wed, Oct 12 2005, Adam Sjøgren wrote:

> On Tue, 11 Oct 2005 23:04:41 +0200, Reiner wrote:
>
> [...]
>> when the content type is application/octet-stream and the file is in
>> fact image/whatever or application/pdf (some broken mailers do), the
>> user should be offered as more reasonable default.
>
>> But in fact this doesn't work (at least for me):
>
> For what it is worth: This works for me. I just chose 'View as type'
> on:
>
>   [2. application/octet-stream; message.wav]...
>
> And was prompted like this:
>
>   View as MIME type: audio/x-wav

I get no default (initial input) when using `t' in with v5-10 or No
Gnus without my patch (tested with a minimal ~/.gnus.el) in the MIME
preview (`mml-preview'):

< #part type="application/octet-stream" filename="/etc/htdig/cookies.txt" disposition=attachment description=foo>
< #/part>
< #part type="application/octet-stream" filename="~/bar.wav" disposition=attachment>
< #/part>

(you need to remove the space before `#'.)

With these MIME part headers (`C-u M-x mml-preview RET'):

,----
| Content-Type: application/octet-stream
| Content-Disposition: attachment; filename=cookies.txt
| Content-Transfer-Encoding: base64
| Content-Description: foo
`----

,----
| Content-Type: application/octet-stream
| Content-Disposition: attachment; filename=bar.wav
`----

Can you show me the MIME part headers or MML part you used?

> (Just a datapoint).

?

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

Re: Bug in "View as type"?

[Adam Sjøgren]

On Wed, 12 Oct 2005 14:31:04 +0200, Reiner wrote:

> On Wed, Oct 12 2005, Adam Sjøgren wrote:

>> For what it is worth: This works for me. I just chose 'View as type'
>> on:

>> [2. application/octet-stream; message.wav]...

>> And was prompted like this:

>> View as MIME type: audio/x-wav

[...]

> Can you show me the MIME part headers or MML part you used?

Sure:

First there is an HTML-part:

 Content-Type: text/html
 Content-Disposition: inline

Then there's the .wav-file:

 Content-Type: application/octet-stream; name=message.wav
 Content-Disposition: attachment; filename=message.wav
 Content-Transfer-Encoding: base64

If I edit the email, the mml-tags are:

 < #multipart type=mixed>
 < #part type=text/html disposition=inline nofile=yes>
 [... html elided ...]
 < #part type=application/octet-stream name="message.wav" filename="message.wav" disposition=attachment buffer=" *mml*">
 < #/part>
 < #/multipart>

(Spaces added by me)

If you want to see the entire raw email, I've put it here:

 <http://www.koldfront.dk/misc/wavattached.txt>

>> (Just a datapoint).

> ?

I was just trying to say that what I wrote was meant as a "here's an
example of that it works for me", not necessarily as "your changes are
bad"... (because I can't really judge that :-))


  Best regards,

-- 
 "I'm a tree-surgeon if you like"                             Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Bug in "View as type"?

[Reiner Steib]

On Wed, Oct 12 2005, Adam Sjøgren wrote:

> On Wed, 12 Oct 2005 14:31:04 +0200, Reiner wrote:
>> On Wed, Oct 12 2005, Adam Sjøgren wrote:
>>> And was prompted like this:
>
>>> View as MIME type: audio/x-wav
>
> [...]
>
>> Can you show me the MIME part headers or MML part you used?
[...]
>  Content-Type: application/octet-stream; name=message.wav
>  Content-Disposition: attachment; filename=message.wav

Okay, I see.  Thanks.

The name can be either in the Content-Type header ("name") or in the
Content-Disposition header ("filename").  I didn't study the relevant
RFCs, but as this function is supposed to be useful when receiving
mails from broken MUAs, I changed it to look at both and use the found
type as DEFAULT instead of INITIAL-INPUT in `completing-read':

	* gnus-art.el (gnus-treat-predicate): Add `first'.
	(gnus-mime-view-part-as-type-internal): Try to fetch `filename'
	from Content-Disposition if Content-Type doesn't provide `name'.
	(gnus-mime-view-part-as-type): Set default instead of
	initial-input.

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