[mew-int 01380] Re: StarSuite

[clemens fischer]

Kazu Yamamoto (³Ü§) <kazu at example.com>:

> On Unix, a program is executed according to CT: with
> mew-mime-content-type.

so on unix, would this program be responsible for mapping
Content-Type to an actual program, like metamail used to do according
to ~/.mailcap (and a little ~/.mime.types)?

> On Win and Mac, "fiber.exe" and "open" is executed according to CT:
> with mew-mime-content-type, respectively.
>
> "Fiber.exe", for example, executes an appropriate application
> according to the suffix of a temporary file which Mew created
> according to Content-Disposition:.

so mew contains a table somewhere mapping Content-* headers to
suffixes.  is this a documented variable users can change?

> mew-mime-content-type is customizable. For example, configure
> mew-prog-postscript with an application to display PostScript, for
> Content-Type: application/postscript.

to be honest, i did not read the code to determine every available
mew variable.  with your explanations, i believe one can use
mew-prog-postscript for treating contents coming in as
"application/postscript".  so there must be a table connecting the
two.  is this an open table?  usually i would not expect a variable
mew-prog-postscript, but rather a table like:

(append mew-content-type-alist '(
     ("application/postscript" . (mew-run-prog "ghostview"))
     ("text/plain" . internal)
     ("text/html" . (mew-run-prog "lynx"))
))

where 'mew-run-prog is a hypothetical function, possibly taking some
useful arguments mew can provide easily (like a temporary file name,
current debug level etc.) and the name of a binary application
program the user wants to handle certain content-types with.  and the
association list mew-content-type-alist would be in the place of many
"small" variables like mew-prog-postscript, the micro$oft data type
handling variables like used to call up staroffice etc.

> Note also that C-uC-cC-e let you specify CT:. If you specify
> application/postscript, for exapmle, mew-prog-postscript will be
> called. The default variable of CT: is guessed by the suffix of its
> filename. This is convenient in a care where an application file is
> labeled with CT: application/octet-stream (ie binary file) and the
> suffix of its file name is correctly specified.

my problem with this is:  how can i specify new MIME types by setting
CT:?  i know i could make up custom MIME types easily if there was a
table.

  clemens