unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Magic MIME
@ 2008-02-10 23:18 Juri Linkov
  2008-02-11  2:24 ` Stefan Monnier
  2008-02-11  4:16 ` Eli Zaretskii
  0 siblings, 2 replies; 8+ messages in thread
From: Juri Linkov @ 2008-02-10 23:18 UTC (permalink / raw)
  To: emacs-devel

Visiting an Arc Lisp file in Emacs fails with the error
"Buffer format not recognized".

Even though Emacs doesn't have an auto-mode-alist entry
associated with Arc, it should visit it in fundamental-mode,
not to fail trying to open it as an archive.  Archive files
have a well-known signature, and using content-based file
type recognition rather than filename-based is more reliable.
This will also improve the recognition of image file formats.

Are there any obstacles to using magic-mime to determine the file
type in Emacs?  If linking libmagic is not possible, then maybe
we could parse the magic.mime file, and even run the `file'
command directly on a visited file?

-- 
Juri Linkov
http://www.jurta.org/emacs/




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Magic MIME
  2008-02-10 23:18 Magic MIME Juri Linkov
@ 2008-02-11  2:24 ` Stefan Monnier
  2008-02-11 20:55   ` Juri Linkov
  2008-02-11  4:16 ` Eli Zaretskii
  1 sibling, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2008-02-11  2:24 UTC (permalink / raw)
  To: Juri Linkov; +Cc: emacs-devel

> not to fail trying to open it as an archive.  Archive files
> have a well-known signature, and using content-based file
> type recognition rather than filename-based is more reliable.

C'mon Juri, you know better than that.  We've been through it with the
image-recognition thingy, so it *should* be clear to everyone on this
list now that content based recognition is no better than filename-based
recognition (and vice versa).  We need to use both.


        Stefan




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Magic MIME
  2008-02-10 23:18 Magic MIME Juri Linkov
  2008-02-11  2:24 ` Stefan Monnier
@ 2008-02-11  4:16 ` Eli Zaretskii
  2008-02-11 20:59   ` Juri Linkov
  1 sibling, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2008-02-11  4:16 UTC (permalink / raw)
  To: Juri Linkov; +Cc: emacs-devel

> From: Juri Linkov <juri@jurta.org>
> Date: Mon, 11 Feb 2008 01:18:41 +0200
> 
> Are there any obstacles to using magic-mime to determine the file
> type in Emacs?  If linking libmagic is not possible, then maybe
> we could parse the magic.mime file, and even run the `file'
> command directly on a visited file?

Whatever the decision is, please avoid relying in external commands
that are not available on all supported platforms.  `file' isn't.

Emacs should be powerful enough to be able to visit files without
requiring an external tool; if it needs to consult some database for
that, it should be easy enough to include such a data base in the
Emacs distribution, perhaps even in a form that is convenient for
reading in Lisp.




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Magic MIME
  2008-02-11  2:24 ` Stefan Monnier
@ 2008-02-11 20:55   ` Juri Linkov
  2008-02-12  3:25     ` Stefan Monnier
  0 siblings, 1 reply; 8+ messages in thread
From: Juri Linkov @ 2008-02-11 20:55 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

>> not to fail trying to open it as an archive.  Archive files
>> have a well-known signature, and using content-based file
>> type recognition rather than filename-based is more reliable.
>
> C'mon Juri, you know better than that.  We've been through it with the
> image-recognition thingy, so it *should* be clear to everyone on this
> list now that content based recognition is no better than filename-based
> recognition (and vice versa).  We need to use both.

Yes, I remember what a mess was the recognition of image files.  But I think
that for other binary formats this could by simplified.  If, say, a file
doesn't start with the "0x8080ffff 0x0000081a" signature there is no sense
to try treating it as an arc archive even if it has the .arc extension.

IIRC, the decision for the image file extensions taking precedence over
the image file content was based solely on the security holes that some
image libraries reportedly have.  So that the user downloaded a .c file
somewhere from the Internet actually with an image inside should not take
the risk of opening it in image-mode in Emacs.

I don't know if such precautions are relevant for other binary formats
like archives.

-- 
Juri Linkov
http://www.jurta.org/emacs/




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Magic MIME
  2008-02-11  4:16 ` Eli Zaretskii
@ 2008-02-11 20:59   ` Juri Linkov
  2008-02-11 21:41     ` Eli Zaretskii
  2008-02-12  3:51     ` Richard Stallman
  0 siblings, 2 replies; 8+ messages in thread
From: Juri Linkov @ 2008-02-11 20:59 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

>> Are there any obstacles to using magic-mime to determine the file
>> type in Emacs?  If linking libmagic is not possible, then maybe
>> we could parse the magic.mime file, and even run the `file'
>> command directly on a visited file?
>
> Whatever the decision is, please avoid relying in external commands
> that are not available on all supported platforms.  `file' isn't.

Emacs could follow the principle of graceful degradation here: if there
is no necessary external command or mime database on the system, then
it will provide less reliable result that will be no worse than the
current without using the magic.mime based file type recognition.

> Emacs should be powerful enough to be able to visit files without
> requiring an external tool; if it needs to consult some database for
> that, it should be easy enough to include such a data base in the
> Emacs distribution, perhaps even in a form that is convenient for
> reading in Lisp.

This is one option  However, I'm not sure if licence conditions of the
mime-magic database allow including it to Emacs.

-- 
Juri Linkov
http://www.jurta.org/emacs/




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Magic MIME
  2008-02-11 20:59   ` Juri Linkov
@ 2008-02-11 21:41     ` Eli Zaretskii
  2008-02-12  3:51     ` Richard Stallman
  1 sibling, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2008-02-11 21:41 UTC (permalink / raw)
  To: Juri Linkov; +Cc: emacs-devel

> From: Juri Linkov <juri@jurta.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 11 Feb 2008 22:59:38 +0200
> 
> > Emacs should be powerful enough to be able to visit files without
> > requiring an external tool; if it needs to consult some database for
> > that, it should be easy enough to include such a data base in the
> > Emacs distribution, perhaps even in a form that is convenient for
> > reading in Lisp.
> 
> This is one option  However, I'm not sure if licence conditions of the
> mime-magic database allow including it to Emacs.

Even if the license precludes that, it can only prevent us from
including the data base verbatim.  If we create our own data base,
with equivalent contents, but in utterly different form, no license
can prevent that, I think, especially if the person who writes that
data base for Emacs never looks at the original data base, but instead
works from a description written by someone else (that someone could
look at mime-magic to produce the description).




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Magic MIME
  2008-02-11 20:55   ` Juri Linkov
@ 2008-02-12  3:25     ` Stefan Monnier
  0 siblings, 0 replies; 8+ messages in thread
From: Stefan Monnier @ 2008-02-12  3:25 UTC (permalink / raw)
  To: Juri Linkov; +Cc: emacs-devel

> Yes, I remember what a mess was the recognition of image files.  But I think
> that for other binary formats this could by simplified.  If, say, a file
> doesn't start with the "0x8080ffff 0x0000081a" signature there is no sense
> to try treating it as an arc archive even if it has the .arc extension.

Agreed.  But just because a file starts with "0x8080ffff 0x0000081a"
shouldn't be enough of a reason to treat it as an arc archive: we need to
look at the filename as well.

> IIRC, the decision for the image file extensions taking precedence over
> the image file content was based solely on the security holes that some
> image libraries reportedly have.

I don't think so.  I do remember that it was decided not to introduce
the two-sided (file-name and file-contents) method so close to
the release.  So now would be a better time.

We could associate "\\.arc\\'" with '(lisp-arc-mode archive-mode)
and associate "0x8080ffff 0x0000081a" to archive-mode (and some other
pseudo-magic thingy for Arc-the-language).


        Stefan




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Magic MIME
  2008-02-11 20:59   ` Juri Linkov
  2008-02-11 21:41     ` Eli Zaretskii
@ 2008-02-12  3:51     ` Richard Stallman
  1 sibling, 0 replies; 8+ messages in thread
From: Richard Stallman @ 2008-02-12  3:51 UTC (permalink / raw)
  To: Juri Linkov; +Cc: eliz, emacs-devel

    Emacs could follow the principle of graceful degradation here: if there
    is no necessary external command or mime database on the system, then
    it will provide less reliable result that will be no worse than the
    current without using the magic.mime based file type recognition.

Unless that gets us big benefits, it is better if we don't use it.
There is an advantage in keeping Emacs self-contained.




^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2008-02-12  3:51 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-10 23:18 Magic MIME Juri Linkov
2008-02-11  2:24 ` Stefan Monnier
2008-02-11 20:55   ` Juri Linkov
2008-02-12  3:25     ` Stefan Monnier
2008-02-11  4:16 ` Eli Zaretskii
2008-02-11 20:59   ` Juri Linkov
2008-02-11 21:41     ` Eli Zaretskii
2008-02-12  3:51     ` Richard Stallman

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).