Guessing based on file extension

Guessing based on file extension

[Lars Magne Ingebrigtsen]

François suggested the following definition of this function:

(defun mm-interactively-view-part (handle)
     "Display HANDLE using METHOD."
     (let ((type (mm-handle-media-type handle)))
       (when (string-equal type "application/octet-stream")
	 (let ((name (mail-content-type-get (mm-handle-type handle) 'name)))
	   (when name
	     (let ((new-type (mm-default-file-encoding name)))
	       (when new-type
		 (setq type new-type))))))
       (let* ((methods
	       (mapcar (lambda (i) (list (cdr (assoc 'viewer i))))
		       (mailcap-mime-info type 'all)))
	      (method (completing-read "Viewer: " methods)))
	 (mm-display-external (copy-sequence handle) method))))

If the type is "application/octet-stream", then we look at the thing
after the dot, and use that as the "real" type.

On the one hand, this is user friendly.  On the other hand, guessing
is yucky.  One could add a used config variable to control whether to
do it or not, but if that defaults to nil, then that won't be very
used friendly.

So.  Whaddayall think?

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

Re: Guessing based on file extension

[Daniel Pittman]

On 02 Jan 2000, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> François suggested the following definition of this function:

[...]

> If the type is "application/octet-stream", then we look at the thing
> after the dot, and use that as the "real" type.
> 
> On the one hand, this is user friendly.  On the other hand, guessing
> is yucky.  

It's somewhat yucky; I can think of quite a number of file-types,
comprising most of what I get sent as attachments, that are identifiable
by extension.

> One could add a used config variable to control whether to do it or
> not, but if that defaults to nil, then that won't be very used
> friendly.

An alist of '((".pdf" "application/pdf") (".txt" "text/plain")) would be
good for this; it lets people set it to what they want (including nil)
-- but populate it with a sane set of things by default.

I would applaud it :)

        Daniel

-- 
The best lack all conviction, while the worst
Are full of passionate intensity.
        -- W.B. Yeats, _The Second Coming_

Re: Guessing based on file extension

[Hans de Graaff]

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

> If the type is "application/octet-stream", then we look at the thing
> after the dot, and use that as the "real" type.
> 
> On the one hand, this is user friendly.  On the other hand, guessing
> is yucky.  One could add a used config variable to control whether to
> do it or not, but if that defaults to nil, then that won't be very
> used friendly.

If application/octet-stream is all we have then gussing may be the
best way to go. Perhaps we could save the first part of the file and
run it through 'file' to see what kind of file it really is? That
would be more foolproof at least than only looking at the file
extension.

Hans

Re: Guessing based on file extension

[Per Abrahamsen]

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

> If the type is "application/octet-stream", then we look at the thing
> after the dot, and use that as the "real" type.
> 
> On the one hand, this is user friendly.  On the other hand, guessing
> is yucky. 

I believe guessing is the thing to do.  Unless the message is from a
Mac or BeOS user, the content-type is almost always the sending agents
best guess based on file extension, and "application/octet-stream"
means that the sending agent couldn't guess anything.  Just because
the the sending agent couldn't guess anything doesn't mean the
receiving agent can't guess the type.

> One could add a used config variable to control whether to
> do it or not, but if that defaults to nil, then that won't be very
> used friendly.

I don't think an option is necessary.

Re: Guessing based on file extension

[Alan Shutko]

Hans de Graaff <graaff@xs4all.nl> writes:

> If application/octet-stream is all we have then gussing may be the
> best way to go. Perhaps we could save the first part of the file and
> run it through 'file' to see what kind of file it really is? That
> would be more foolproof at least than only looking at the file
> extension.

On my system, both Word documents and Excel documents turn up as
"Microsoft Office Document"s in file, but I want to use different
programs to view them.  (On other Unix systems, they don't tend to
have anything meaningful turn up in file.)

Given that it's usually Microsoft OS programs which say everything is
application/octet-stream, and all _they_ do upon receiving the
document is look at the file extension, I don't see a major problem
with doing the same thing.  (I mean, they don't even look at the
content-type when it _is_ meaningful.)

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
In most instances, all an argument proves is that two people are present.

Re: Guessing based on file extension

[Steinar Bang]

>>>>> Per Abrahamsen <abraham@dina.kvl.dk>:

> I believe guessing is the thing to do.  Unless the message is from a
> Mac or BeOS user, the content-type is almost always the sending
> agents best guess based on file extension, and
> "application/octet-stream" means that the sending agent couldn't
> guess anything.

In the case of one major offender, MS Outlook and Outlook Express,
"wouldn't" is a better description than "couldn't".

Re: Guessing based on file extension

[Simon Josefsson]

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

> On the one hand, this is user friendly.  On the other hand, guessing
> is yucky.  One could add a used config variable to control whether to
> do it or not, but if that defaults to nil, then that won't be very
> used friendly.
> 
> So.  Whaddayall think?

Here's an idea:

Nothing is changed in the article buffer (it still says
'application/octet-stream'), but there's a new entry in the
right-button popup-menu which say 'View as application/ms-word' or
whatever the guessed MIME type is.

IMHO this would make it easy enough to use for Gnus users, by the same
time it make it obvious that viewing the attachment as a
application/ms-word file might be the Wrong Thing under some
circumstances and leave the choice to the user.

Re: Guessing based on file extension

[Hans de Graaff]

Alan Shutko <ats@acm.org> writes:

> On my system, both Word documents and Excel documents turn up as
> "Microsoft Office Document"s in file, but I want to use different
> programs to view them.  (On other Unix systems, they don't tend to
> have anything meaningful turn up in file.)

I suppose I could have checked that before making the suggestion. On
my system Excel sheets are correctly recognized (with version number
no less), but Word documents are seen as `data'. Perhaps this
`solution' will cause more problems than it was set out to solve,
then, and plaing guessing based on the extension may be the way to go.

Hans

Re: Guessing based on file extension

[Steinar Bang]

>>>>> Simon Josefsson <jas@pdc.kth.se>:

> Nothing is changed in the article buffer (it still says
> 'application/octet-stream'), but there's a new entry in the
> right-button popup-menu which say 'View as application/ms-word' or
> whatever the guessed MIME type is.

> IMHO this would make it easy enough to use for Gnus users, by the same
> time it make it obvious that viewing the attachment as a
> application/ms-word file might be the Wrong Thing under some
> circumstances and leave the choice to the user.

I like this approach.

Re: Guessing based on file extension

[François Pinard]

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

> François suggested the following definition of this function [...]
> If the type is "application/octet-stream", then we look at the thing
> after the dot, and use that as the "real" type.

The few replies we saw show that opinions seem to be a bit split, and it
might be difficult to reach a real consensus.  On the other hand, status
quo, just for avoiding the choice, might not be the ideal solution either.

> On the one hand, this is user friendly.  On the other hand, guessing is
> yucky.  One could add a used config variable to control whether to do it
> or not, but if that defaults to nil, then that won't be very used friendly.

One negative side-effect would be that, if Gnus gets too clever at deciding
the MIME type despite application/octet-stream, Gnus users might lean more
easily towards just letting it default in, or might use Gnus as a proof
of concept against more proper usage.  But as a receiving user, I would
like that Gnus be more helpful at recognising types despite the laziness
of the submitter programs, and use proper in-lining whenever possible.

Simon Josefsson <jas@pdc.kth.se> writes:

> [...] viewing the attachment as a application/ms-word file might be the
> Wrong Thing under some circumstances and leave the choice to the user.

This is probably an orthogonal issue, so we have to be careful here at
seeing both aspects well separate, with clear mind.  The bad of a thing
is not necessarily the bad of the other.

If someone wants to prohibit automatic in-lining of application/ms-word
MIME entities, say (I do not even know if Gnus currently allows it, but
just let's suppose it can, for the argument), then the Gnus behaviour is
already fine-tunable.  Lars gave us a lot of variables to customise how
various MIME types get in-lined, preferred, and displayed.  Let's presume
Gnus has already been set to user's taste, in this area.

What would be interesting, in practice, is letting Gnus derive the MIME
type from the file extension, given we have application/octet-stream.
The customisation will then apply over that derived MIME type, as usual.

It is surely sad that so many messages use that application/octet-stream as
a catch-all type.  As a user receiving many such messages, I would prefer
that Gnus does not make me more sad than the situation is already.  It could
help better, and the little code I submitted is an attempt in that direction.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Guessing based on file extension

[Kai Großjohann]

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

> If someone wants to prohibit automatic in-lining of application/ms-word
> MIME entities, say (I do not even know if Gnus currently allows it, but
> just let's suppose it can, for the argument), then the Gnus behaviour is
> already fine-tunable.  Lars gave us a lot of variables to customise how
> various MIME types get in-lined, preferred, and displayed.  Let's presume
> Gnus has already been set to user's taste, in this area.

Hm.  So the conservative choice would show a button for the foo.gif
that's tagged as application/octet-stream, and there is a menu entry
for viewing that as image/gif.  And the progressive choice would
inline the gif.  Hm.

I kinda tend towards the conservative side, here, but that feature is
surely a nice one.  Hm.  Hmmm.

kai
-- 
A large number of young women don't trust men with beards.
(BFBS Radio)

Re: Guessing based on file extension

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* François Pinard <pinard@iro.umontreal.ca>  on Tue, 04 Jan 2000
| The few replies we saw show that opinions seem to be a bit split, and it
| might be difficult to reach a real consensus.  On the other hand, status
| quo, just for avoiding the choice, might not be the ideal solution either.

When in doubt, ask the user.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4cooPgl+vIlSVSNkRAu1nAJ46ARQkbMwNQznSyfYM5KhIWscJ8QCfcBbp
e4nFNfRBNBRNtSqkHCJkVjA=
=3dqp
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Do not use Happy Fun Ball on concrete.
Minion of Nathan - Nathan says Hi! \ 
PGP Key: at a key server near you!  \ 

Re: Guessing based on file extension

[Steinar Bang]

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

> It is surely sad that so many messages use that
> application/octet-stream as a catch-all type.  As a user receiving
> many such messages, I would prefer that Gnus does not make me more
> sad than the situation is already.  It could help better, and the
> little code I submitted is an attempt in that direction.

Hm... indeed.  If it did, I would lose one of the two reasons I
currently have for dragging my heels wrt. a switch to IMAP: editing
the MIME types of attachments (the other one is reparenting of
articles, both are related to article editing).

Re: Guessing based on file extension

[Kim-Minh Kaplan]

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

Steinar Bang writes:

> Hm... indeed.  If it did, I would lose one of the two reasons I
> currently have for dragging my heels wrt. a switch to IMAP: editing
> the MIME types of attachments (the other one is reparenting of
> articles, both are related to article editing).

Ohh, I must have forgotten to post a patch that fixes a bug in the
MIME parts menus on the "View As Type..." entry.  I just upgraded it
with François Pinard's idea: default to a guessing based on file
extension.  Now you can easily view attached parts without editing the
article.

Kim-Minh.



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: =?nil?b?bW9kaWZpY2F0aW9uIHRvIGdudXMtYXJ0LmVs?= --]
[-- Type: text/x-elisp, Size: 992 bytes --]

(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))
	 (def-type (and name (mm-default-file-encoding name))))
    (and def-type (cons def-type 0))))

(defun gnus-mime-view-part-as-type (mime-type)
  "Choose a MIME media type, and view the part as such."
  (interactive
   (list (completing-read
	  "View as MIME type: "
	  (mapcar (lambda (i) (list i i)) (mailcap-mime-types))
	  nil nil
	  (gnus-mime-view-part-as-type-internal))))
  (gnus-article-check-buffer)
  (let* ((handle (get-text-property (point) 'gnus-data)))
    (gnus-mm-display-part
     (mm-make-handle (mm-handle-buffer handle)
		     (cons mime-type (cdr (mm-handle-type handle)))
		     (mm-handle-encoding handle)
		     (mm-handle-undisplayer handle)
		     (mm-handle-disposition handle)
		     (mm-handle-description handle)
		     (mm-handle-cache handle)
		     (mm-handle-id handle)))))