On 27Apr2015 09:23, martin f krafft <[email protected]> wrote:
also sprach Cameron Simpson <[email protected]> [2015-04-26 22:54 +0200]:
Apphelper first asks whether to view the file, offering the
supplied view command in [square brackets] as the default. Pressing
return or entering "y" or "yes' accepts this default and runs the
viewer. Entering "n" or "no" skips running the viewer. Other
answers are taken to be the name (and optional arguments) of a
viewing program.
Superficially that sounds like exactly what you're asking for.
Yes, it does and thanks for being so persistent. I am sorry for
being finicky about this, but I know how things go and I don't want
to have to press <enter> 99% of the time just to accept a default so
that I can select a different viewer in 1% of the cases.
That is why my "ah" wraper (specific to my own preferences) passes the "-y"
option to apphelper. Note also that apphelper honours a $APPHELPER_OPTS
environment variable so you can tune your default options.
What I really want is <view-attach> to grow a sibling:
<edit-attach>, which would spawn run-mailcap --action=edit instead
of the default --action=view. And then I could view or edit at the
press of one of two button without having to engage in an
interactive session requiring me to react to prompts.
Sounds like a job for a mutt macro. A first cut would be to write a macro which
pointed $mailcap_path at a different mailcap file, then ran view-attach, then
restored the old value.
Keeping two mailcaps can be tedious unless you autogenerate one from the other,
eg by making the "ask" version prepend apphelper or similar to the front of end
mailcap command.
Another approach would be a macro that pipes the attachment into a script that
saves its input (making your temp file) and prompts for a command to issue with
that file.
If mutt had a "setenv" command you could also write a macro to set an
environment variable (eg $APPHELPER_OPTS for apphelper) before invoking
<view-attach>, causing different behaviour from the same mailcap command. Eg to
make apphelper ask or not ask about the viewer.
But it doesn't, AFAIK.
yet anothe possibility: let me direct your attention to mutt's <view-mailcap>
command, bound to "m" in the attachments menu. (<return> runs "view-attach".)
view-mailcap is described in section 3.2.2 "Search Order" in the mutt manual.
I have just read it 3 or 4 times and believe I now have a slight handle on what
it does. It might be possible to adapt it to get you a "view with default"
(<return>) and a view with question for command (<view-mailcap>/"m"). I am not
yet convinced though.
I do not properly understand <view-mailcap> versus <view-attach>. I would
appreciate someone else chiming in here.
Alternatively, this could probably be solved even more generically
e.g. by allowing a sequence like '%' to appear in the <shell-escape>
command line, which, if present, causes a temporary file to be
written and injected into the command line. I bet there could be
plenty of use-cases for this. The advantage of letting mutt write
the temporary file is that mutt knows more about the file than
children commands. mutt could even substitute %n for the filename
and %t for the mime-type.
Yes, that would help.
Cheers,
Cameron Simpson <[email protected]>
Yes, [congress is] petty and venal and selfish. That's why they're called
_representatives_. - Will Durst
