Re: [PATCH] Add execute-command() widget function (was Re: [RFC][PATCH] Add change-directory() widget function)

[Bart Schaefer <schaefer@brasslantern.com>]

I'm trying not to be a wet blanket here, but:

You've accidentally included the doc for zrestart in the .yo patch.

The -e option is never going to do anything useful, because send-break
will kill the buffer to which the command has just been written.  (I
feel as though I've said this before about a different proposed
widget.  Hm.)  If you wrote to the buffer before calling print -z that
might make some sense, but more so at PS1 than PS2.

Attempting to pass multiple commands, one per positional argument, and
then eval them all at once with newlines between, strikes me as
inviting all kinds of quoting problems, plus obscures the return
status if some command in the middle of the list fails.

It's not safe to use eval that way to assign to $ops[-v], the argument
passed to -v might not be a simple variable name.  E.g. if the user
forgets the variable name, the first command they intended to execute
will be stored there instead.  Using a single well-known (documented)
name instead of passing an argument would avoid this, and it's not as
though you can have two execute-commands simultaneously that would
introduce a conflict.

Other things that occurred to me not directly related to this patch:

There's nothing preventing the user from passing more "zle" commands
to execute-commands which could arbitrarily mess up your print -z ...
heck, execute-commands could even be caused to call itself
recursively.  This is not something you need to try to code around,
but it could be documented as a misuse.

Instead of throwing an error when there are no commands provided,
execute-commands could invoke read-from-minibuffer to input a command
to run, much like the builtin execute-named-cmd does for widget names.
That could make execute-commands into a widget rather than just
something callable from widgets.