vi and mutt problem

[Michael]

This is on an Slackware system. I only have root my regular user accounts.
When I am finished writing an email, I get something similar at bottom of my 
mutt screen:
Error running "vi '/tmp/mutt-MarahIII-1000-2799-33'"!

I have tried using:
set editor="/usr/bin/elvis"
set editor="vi"
set editor="/usr/bin/vi"
and even commenting out the line all together.

No matter what, I get the same "error".
I check the /tmp directory and see the two mutt files and I think the error 
always relates to message no sent.


Any help?

Thanks.

Mike

for IMAP folder

[peng shao]

Hi. I set up mutt with several local mailboxes and a gmail IMAP. By
now it works well except that the  function. If I
have new email in my local mailboxes fetched by getmail, then the
 can take me to it correctly. However if there is
one new email in the gmail IMAP, then the  simply
tells me "no mailboxes have new mail". Is there anyway I can tell mutt
to treat IMAP like a normal folder so that the 
can find it?


Thank you for any concern.

Peng

Re: relation between folder-hook and push

[Toby Cubitt]

On Fri, March 19, 2010 3:02 am, rog...@sdf.org wrote:
>>On 2010-03-18, peng shao  wrote:
>>Folder hooks are processed as the manual says.  However, the push
>>command pushes its arguments onto a stack and mutt's input parser
>>later pops those arguments off the stack to parse and execute them.
>>It's that pushing and popping that reverses the order of your pushed
>>commands.  The solution is to enter those folder hooks that contain
>>pushes into your muttrc "upside down", like this:
>>
>>folder-hook inbox 'push :inbox'
>>folder-hook . 'push :default'
>>
>>It would be nice to be able to put commands into a queue rather than
>>onto a stack.  I don't know why it is the way it is.
>
> I'm going to take a guess at this one, but when I see stuff like this,
> it means the code is optimized to take the fewest cpu cycles possible
> vs. spending a few extra cpu cycles processing a queue.  On slow CPU's,
> makes perfect sense.  Faster cpus, users will always question with
> "Why???". ;-)
>
> I prefer optimized but easy to read code, with good comments.

A queue really isn't much harder to code than a stack (and most *nix
systems have a queue library), and even on slow CPU's the difference will
be insignificant; mutt's command stack is only ever likely to contain a
handful of pushed commands waiting to be processed.

It's probably too late to change this in mutt, though.

Toby
-- 
Dr T. S. Cubitt
Quantum information theory group
Department of Mathematics
University of Bristol
United Kingdom