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

Re: simulating "Aborted unmodified message" condition



On 2006-09-11, William Yardley <mutt-users@xxxxxxxxxxxxxxxxx> wrote:
> On Mon, Sep 11, 2006 at 04:14:38PM -0700, Gary Johnson wrote:
> > On 2006-09-11, William Yardley <mutt-users@xxxxxxxxxxxxxxxxx> wrote:
> 
> > > Maybe a better way of explaining...
> > > 
> > > I'm trying to do the equivalent of what :q! does in vim within a script.
> > > 
> > > So what would be most helpful would be a simple explanation of how
> > > message editing exactly works in mutt - the editor is invoked with a
> > > temporary filename passed to it by mutt - how does mutt know when the
> > > editor has written to the file or quit without writing to it?
>  
> > Mutt then waits for the call to system() to return, which happens 
> > when the user quits the editor.  Mutt then
> > 
> >     5.  checks the mtime of the temporary file.
> >     6.  If the mtime has changed, mutt
> >             a)  displays the compose menu,
> >             b)  waits for the next command from the user and 
> >                 processes it accordingly.
> >         else, mutt
> >             a)  prints "Aborted unmodified message".
> >     7.  Mutt deletes the file.
> >     8.  Mutt waits for the next command from the user.
> 
> Thanks - I understand a little better now, and I think I fixed the
> problem that was causing this before (I originally did do it more or
> less the right way but got confused at some point).
> 
> So now my only problem is that the macro, which is like:
>  macro index M ":set editor=~/bin/mutt_mailman_approve.pl<enter> \
>   <view-attachments><last-entry><search-reverse>message/rfc822<enter> \
>   <reply><send-message>:set editor=\"vim +'/^$/+2'\"<enter><exit>"
> 
> doesn't work right if I abort the message, because editor never gets
> reset, and the rest of the macro is interpreted literally. Pretty sure
> there's no good workaround for this, though... 

You're welcome.  I think you're right about the macro, though.  I 
can't think of any workaround either.

Since you don't want mutt to really send the message, though, 
mightn't it work to pipe the attachment to your script instead of 
attempting to reply to it, maybe setting pipe_decode first?

Regards,
Gary

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