Re: problem with push-line-or-edit and precmd?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jan 17,  1:39am, Greg Klanderman wrote:
}
} So this is only a problem for push-input and push-line-or-edit?

Yes.

} I know it might not be the most elegant solution, but could some
} global be set to inhibit the running of precmd and/or clear the error
} status when these commands are used?

Let's talk a little about the wider context.

The trouble, as I now recall, is this:

Controlling the whole "editor session" is the zsh command parser.  It's
asked by the ultimate top-level command loop to read one command from
the shell input; this in turn invokes ZLE.  When you hit accept-line at
the end of that first line of a multi-line construct, control returns
to the parser, which discovers that it doesn't yet have a fully formed
command.  The parser sets up the prompt level state, etc., and then
starts a new ZLE "session" to get the next chunk of the command.

This means that the only way for ZLE to get back control at the start
of the multi-line construct is to force the *parser* to abandon *its*
idea of what has been read so far, and restart as a new command.  And
the only [both relatively clean and already implemented] way to force
the parser to restart is to convince it that the user interrupted the
editor, i.e., to set errflag and let the parser deal with it.

This therefore means that it's impossible for a user-defined widget to
use push-input, or push-line-or-edit, and then proceed with other zle
activities, because as soon as one of those builtins has been called
the entire editor and parser state is for all useful purposes gone. 
Even if we implemented a global flag to tell the parser "hey, this is
not really an error, pretend nothing happened" it still doesn't solve
the underlying problem that in order to reset the parser state you
have to abandon the widget in progress and unwind the call stack.