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

[Marlon Richert <marlon.richert@xxxxxxxxx>]

Paul, you wrote in workers/48408: "I can write a proper widget."

Any chance you might feel like continuing where I left off, below? :)

On Sat, May 1, 2021 at 4:30 PM Marlon Richert <marlon.richert@xxxxxxxxx> wrote:
>
> OK, I give up. Someone else can finish this.
>
> On Fri, Apr 30, 2021 at 11:25 PM Bart Schaefer
> <schaefer@xxxxxxxxxxxxxxxx> wrote:
> >
> > 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.