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

[Bart Schaefer <schaefer@brasslantern.com>]

On Wed, Apr 21, 2021 at 2:28 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> [ Aside: does anyone use zyodl.vim?  I see I have some local mods and
> not sure how much to prioritize cleaning them up and pushing them. ]

I've got an emacs yodl-mode somewhere, which is what I use when I
happen to find it ... it may be lurking on a host I rarely access any
more.

> Again, please wrap long lines in your prose.  This is the third time you
> are being asked to do so.

In order of (my personal) preference ...
++ send messages to the list in plain text with 78-column-or so lines
   (except don't line-wrap code**)
++ or send in plain text with long lines to avoid wrapping code
++ or send in HTML so lines are automatically wrapped***

** which admittedly is something I can't currently enforce on my own mailer.
*** which I sometimes do by accident because gmail replies in HTML if
the replied-to message was HTML.

> As to PUSHD_MINUS and PUSHD_SILENT, it would be better to give an
> example doesn't change them from their default values.

Using "pushd -q ..." avoids the need for PUSHD_SILENT.  Sadly there's
no way to temporarily disable PUSHD_MINUS except to setopt it in the
widget body.

> [...] the implementation uses «BUFFER="$*"» but
> the command is passed as an array [... either]
> commands should be passed as a single string, or the assignment to
> BUFFER should be changed

For example, «BUFFER="${(q-)*}"»

> > @@ -0,0 +1,54 @@
> > +# This function lets you implement widgets that can execute arbitrary commands
>
> DRY.  This information is in the manual, so it isn't needed here.

There's precedent for having similar doc in function source files and
also in the manual, so that someone perusing the files doesn't have to
then look to see whether the function is also in the manual.

> > +    # Move the entire current multiline construct into the editor buffer. This
> > +    # function is then aborted and we return to the top-level prompt, which
> > +    # triggers the hook above.
> > +    zle .push-line-or-edit
> > +    return  # Not actually necessary, but for clarity's sake
>
> How is it not necessary?  If control flow continued past the «esac»,
> code would be executed.

Flow can't continue past «zle .push-line-or-edit» because it invokes
the equivalent of send-break and kills the widget.  But I still don't
understand why he wants this here.

> If the user presses the bound key at the select prompt or in vared, why
> should the library function disregard that?

This was my suggestion, because at a select prompt the command
wouldn't be "executed", it'd be fed to select as the value of the
selection, which would be surprising at the least.

In vared it would replace the contents of the variable with the
command string and then exit vared, which is probably also not wanted.
I didn't think of that case, but it's a good catch IMO.

> Shouldn't this behaviour be
> changed?  Or failing that, documented?

Documented, unless you have a suggestion for what to change it to be.