I'm not sure I used the correct terminology in the Subject: line, but what I'm looking for is pretty easy to explain (hopefully easy to implement also :p). Basically, this is what we have now:
auto_view image/tiff
This line tells mutt to consult $mailcap_path and find a mailcap entry
that corresponds to the MIME type and display it. Well, as you can see
from this particular example, you're not going to get anything useful
from a TIFF file on a 80x24 terminal (and no, aaview is not an
acceptable answer :)). So, what one does is create a mutt-specific
.mailcap file that has a line for image/tiff which, instead of calling a
graphic viewer like qiv/ee/xv/etc, calls something like tiffinfo that
displays some properties of the image instead, so at least you can get
_something_ useful out of it.
Well, I like this behaviour by itself, but I think this is only one
example of a whole class of cases where the "viewer" desired for an
inline, auto_view environment is a lot different from the viewer one
would normally use for a given file type.
In other words, I think it would be good to have something like this:
auto_view image/tiff tiffinfo '%s'
In theory, if any more arguments appear after the first argument
(the type argument, in this case 'image/tiff') then they are assumed
to be a mailcap-format capabilities line. Of course, it wouldn't
have/want to be a full-featured implementation, since most of the
mailcap fields would be irrelevant in an auto_view context (like
"compose", "composetyped", etc), but maybe "test" and "notes" could
be used somehow. *shrug* The point of all this, is that you now have
a viewer specifically for auto_view, which is displaying files out of
their native environment most of the time. So, now when you go to the
view attachments menu and select one, you can actually execute it with
an image viewer or whatever, instead of having to save it to disk
first and then manually run it, or take the time to use the pipe-entry
function which may not work if the viewer command doesn't accept stdin.
By the way, I have read this from Section 5.3 of the manual:
----- cut here
In addition, you can use this with Autoview to denote two commands for
viewing an attachment, one to be viewed automatically, the other to be
viewed interactively from the attachment menu. In addition, you can then
use the test feature to determine which viewer to use interactively
depending on your environment.
text/html; netscape -remote 'openURL(%s)' ; test=RunningX
text/html; lynx %s; nametemplate=%s.html
text/html; lynx -dump %s; nametemplate=%s.html; copiousoutput
----- cut here
This solution works Most Of The Time(tm), but is a bit inelegant in
that it co-opts the "copiousoutput" flag for mutt use.
I think adding this extra functionality to the auto_view function
would eliminate the need for a lot of the "mutt-specific mailcap files"
that are out there, and should be implementable without a whole lot of
coding; in other words, when mutt goes to autoview a particular file as
a result of the auto_view command, it sees that there is already an
instruction on the command line and just uses that instead of calling
the function that searches the mailcap files for a corresponding line.
Of course, generating a compliant mailcap-style line that views the
attachment in the pager without errors would be the user's
responsibility; but it already is when generating mailcap files.
--
------------------------------------------------------------------------
John Buttery
(Web page temporarily unavailable)
------------------------------------------------------------------------
msg25035/pgp00000.pgp
Description: PGP signature
