<<< Date Index >>>     <<< Thread Index >>>

Re: Viewing attachments with detached process while remianing in attachments menu



On 2007-01-18, Eric Smith <es@xxxxxxxxxxxx> wrote:
> Like in other mail clients I just want to press on the selected
> attachment and view it and then go down to the next and view it.
> So I may open any number of the attachments at one time.

That's how I have my mutt configured and it works very well.

> To detach I am using a mailcap recipe of:
> image/jpg; sh -c "exec display %s > /dev/null 2>&1 &"

I'm not sure how much difference it makes to our results, but I use 
this:

    image/*; mutt_bgrun xv %s; test=test "$TERM" != "screen" && RunningX

The test tries to keep me from trying to run xv in the wrong 
environment.  We can ignore it here.  The mutt_bgrun script copies 
the temporary file %s to another location, runs xv on that file in 
the background, and returns to mutt.  It also removes the copy of 
the temporary file when xv exits.

> When I concatenate in .muttrc or on the mutt colon command line
> as followS:
> 
> view-attach exit

I assume that you mean that from the attach menu, you execute

    :exec view-attach exit

> The viewing does not work properly, (xview no-op and display
> gives an X windows fiule listing option).

It works fine for me.

When your

    sh -c "exec display %s > /dev/null 2>&1 &"

command returns to mutt, mutt immediately overwrites the temporary 
file with nulls, then removes (unlinks) the file.  There is a race 
condition between the opening and reading of the file by your viewer 
and the writing and removing of the file my mutt.  In the cases 
where your viewer fails, it probably loses the race.

> When I just go view-attach the viewing works fine but I get
> plonked into the Pager and have to exit from there.

I assume "just go view-attach" means you execute

    :exec view-attach

That should put you back in the attach menu, not in the pager.  I 
don't know how you would get from the attach menu to the pager 
without an exit command.  Did I miss a step?  I also don't know why 
the viewer would work in this case but not in the previous case.  As 
I recall from mutt's code, it doesn't do anything between the return 
of the system() call the executes the viewer and the overwriting and 
removing of the temporary file.

> How do i fix this?  Is it too much to ask that this
> works out of the box?  Ot am I missing some things?

It should work fine, except for the race-condition problem.  You can 
solve that to a degree by adding a sleep command to your viewer 
command, e.g., 

    sh -c "exec display %s > /dev/null 2>&1 & sleep 2"

That should give your viewer a chance to run before mutt proceeds.  
Of course you then have to wait 2 seconds, or whatever sleep time 
you choose, to regain control of mutt.  Also, 2 seconds may not be 
long enough for some viewers.  A better choice is the mutt_bgrun 
script or the equivalent.  You can find out more about it here:

    http://www.spocom.com/users/gjohnson/mutt/#background

> Even nicer would be an open-all-attachment macro.

That would be nice, but there doesn't seem to be a way to do that.  
For one thing, I don't see a way to tag attachments according to 
patterns the way you can tag messages from the index menu.  For 
another, after manually tagging attachments in the attachment menu, 
the tag prefix (;) seems to have no effect when followed by an 
<Enter>.  This may be a bug.  I'm running mutt-1.5.12.

HTH,
Gary

-- 
Gary Johnson                               | Agilent Technologies
garyjohn@xxxxxxxxxxxxxxx                   | Wireless Division
http://www.spocom.com/users/gjohnson/mutt/ | Spokane, Washington, USA