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

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

[Greg Klanderman]

Hi,

I just noticed this while testing a patch to add a special
zle-line-finish widget, and thought it was due to my changes
but have now found the same behavior in pristine 4.3.9 and
4.2.5 builds.

Running "zsh -f",

lwm% function foo () { return $1 }
lwm% function precmd () { local x=$? ; (( $x != 0 )) && echo "=> exit status $x" }
lwm% foo 4
=> exit status 4
lwm% true
lwm% 
lwm% echo '                       ## type: <return>
quote>                            ## type: ESC-x push-line-or-edit <return>
=> exit status 1
lwm% echo '

Notice the precmd is run when the push-line-or-edit widget is invoked,
and that $? is set to 1 in the precmd.

Is it expected that precmd would be run here?

And if so, why is a non-zero exit status set?

thanks,
Greg

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

[Bart Schaefer]

On Jan 16,  5:21pm, Greg Klanderman wrote:
}
} Notice the precmd is run when the push-line-or-edit widget is invoked,
} and that $? is set to 1 in the precmd.
} 
} Is it expected that precmd would be run here?
} 
} And if so, why is a non-zero exit status set?

This is an admitted misfeature of the push-line-or-edit implementation,
which in order to accomplish its purpose of invoking the editor on the
multi-line buffer as a single editable region, does almost exactly the
equivalent of

	print -z "$BUFFER"
	zle send-break

This causes the current zle "session" to abort, which returns from the
PS2 or deeper prompt all the way to the top level, at which point the
editor re-initializes at the PS1 prompt and pops the buffer stack and
you're back where you want to be.

The side-effects of this include that a zle widget can't do anything
after push-line-or-edit (the widget forcibly exits), the status is
set to nonzero, and precmd runs because the editor has restarted, all
as if the user hit ctrl+c.

This is one case where a change would be welcome, if a better way could
be found to trash the entire nested editor context up from whatever
prompt level you're reached, and thereby reset at PS1.

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

[Greg Klanderman]

>>>>> Bart Schaefer <schaefer@brasslantern.com> writes:

> The side-effects of this include that a zle widget can't do anything
> after push-line-or-edit (the widget forcibly exits), the status is
> set to nonzero, and precmd runs because the editor has restarted, all
> as if the user hit ctrl+c.

So this is only a problem for push-input and push-line-or-edit?

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?

I really can't believe I never noticed this, I use those commands all
the time, and have had a precmd like that forever.

thanks,
Greg

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

[Bart Schaefer]

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.