Cannot use LBUFFER+= nor print -zr from zsh/sched call

Cannot use LBUFFER+= nor print -zr from zsh/sched call

[Sebastian Gniazdowski]

Hello,
I do:

    zle .redisplay
    zle .kill-buffer
    LBUFFER+="${(j:; :)commands[@]}"
    print -zr "${(j:; :)commands[@]}"
    print -rl -- "${commands[@]}"

And command line isn't feed with the $commands. Whole code:

https://github.com/psprint/zconvey/blob/dc2656f1f8a91c7af03d344eab34644dfb8b96c3/zconvey.plugin.zsh#L183-L188


Is there workaround? How to feed commands to command line from sched call?

Best regards,
Sebastian Gniazdowski

Re: Cannot use LBUFFER+= nor print -zr from zsh/sched call

[Sebastian Gniazdowski]

I've added a simple TIOCSTI based program:

void output( char *cmd ) {
    if ( cmd && strlen( cmd ) > 0 ) {
        size_t size = strlen( cmd );
        unsigned int i;
        char *c;
        for (i = 0; i < size; i++) {
            c = cmd + i;
            ioctl( 0, TIOCSTI, c );
        }
        printf("\n");
    }
}

https://github.com/psprint/zconvey/blob/master/feeder/feeder.c#L15-L26

It works great compared to previous LBUFFER+= etc. attempts. However,
there is a problem with obtaining accept-line. If I use '\n' in
feeder.c, the line gets accepted, but not from sched call. A zle
.accept-line will work for e.g. "echo" or "ls" commands but with
errors (takes only first characters). How to find exit from this?
Also, could some update be done to Zsh, so that Zsh 5.3 will be
workaround-less?

The behavior currently:
https://asciinema.org/a/7yw5jq656tfmqzt1yhkrhcd6n


Best regards,
Sebastian Gniazdowski


On 11 September 2016 at 11:28, Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
> Hello,
> I do:
>
>     zle .redisplay
>     zle .kill-buffer
>     LBUFFER+="${(j:; :)commands[@]}"
>     print -zr "${(j:; :)commands[@]}"
>     print -rl -- "${commands[@]}"
>
> And command line isn't feed with the $commands. Whole code:
>
> https://github.com/psprint/zconvey/blob/dc2656f1f8a91c7af03d344eab34644dfb8b96c3/zconvey.plugin.zsh#L183-L188
>
>
> Is there workaround? How to feed commands to command line from sched call?
>
> Best regards,
> Sebastian Gniazdowski

Re: Cannot use LBUFFER+= nor print -zr from zsh/sched call

[Bart Schaefer]

On Sep 11, 12:35pm, Sebastian Gniazdowski wrote:
}
} I've added a simple TIOCSTI based program:

Er, no.  Just no.  Please delete this code and go watch silly cat videos
until you've forgotten you ever wrote it.

Re: Cannot use LBUFFER+= nor print -zr from zsh/sched call

[Bart Schaefer]

In case it wasn't obvious ...

On Sep 11,  6:13pm, Bart Schaefer wrote:
}
} Er, no.  Just no.  Please delete this code and go watch silly cat videos
} until you've forgotten you ever wrote it.

This was intended as a joke, so please laugh at it (or at me, if needed).

Re: Cannot use LBUFFER+= nor print -zr from zsh/sched call

[Sebastian Gniazdowski]

On 12 September 2016 at 17:06, Bart Schaefer <schaefer@brasslantern.com> wrote:
> In case it wasn't obvious ...
>
> On Sep 11,  6:13pm, Bart Schaefer wrote:
> }
> } Er, no.  Just no.  Please delete this code and go watch silly cat videos
> } until you've forgotten you ever wrote it.
>
> This was intended as a joke, so please laugh at it (or at me, if needed).

;) It's just that I'm so happy with TIOCSTI that didn't know what to
respond. The ZLE solution you gave is ok, but sched can start without
zle == true

Best regards,
Sebastian Gniazdowski

Re: Cannot use LBUFFER+= nor print -zr from zsh/sched call

[Bart Schaefer]

On Sep 12,  5:24pm, Sebastian Gniazdowski wrote:
}
} The ZLE solution you gave is ok, but sched can start without zle == true

Well, yes.  It should be fine to do e.g.:

    if zle; then
      zle -U "${(j.;.)commands}"
    else
      print -zr "${(j.;.)commands}"
    fi

If zle is not yet running, then it's going to start up the very next
thing, and will pop the buffer stack onto the new command line.

If you want an implicit accept-line, then you're going to have to do
something to coordinate with zle-line-init in the "else" branch.

Re: Cannot use LBUFFER+= nor print -zr from zsh/sched call

[Sebastian Gniazdowski]

On 12 September 2016 at 19:34, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Sep 12,  5:24pm, Sebastian Gniazdowski wrote:
> }
> } The ZLE solution you gave is ok, but sched can start without zle == true
>
> Well, yes.  It should be fine to do e.g.:
>
>     if zle; then
>       zle -U "${(j.;.)commands}"
>     else
>       print -zr "${(j.;.)commands}"
>     fi
>
> If zle is not yet running, then it's going to start up the very next
> thing, and will pop the buffer stack onto the new command line.
>
> If you want an implicit accept-line, then you're going to have to do
> something to coordinate with zle-line-init in the "else" branch.

The zle-via-widget method works:

function __convey_zle_paster() {
    zle .kill-buffer
    LBUFFER+="$*"
    zle .redisplay
    zle .accept-line
}
zle -N __convey_zle_paster

Except it doesn't accept the buffer. I don't know how to coordinate
with zle-line-init, any hints maybe? And it will be hard to do with
print -zr.. So I include this method as option:

# To put commands on command line, Zconvey can use small program "feeder".
# Or "zsh" method, which currently doesn't automatically run the command – to
# use when e.g. feeder doesn't build (unlikely) or when occurring any problems
# with it

zstyle ":plugin:zconvey" output_method "feeder"

Best regards.
Sebastian Gniazdowski

Re: Cannot use LBUFFER+= nor print -zr from zsh/sched call

[Bart Schaefer]

On Sep 13,  5:44pm, Sebastian Gniazdowski wrote:
} Subject: Re: Cannot use LBUFFER+= nor print -zr from zsh/sched call
}
} The zle-via-widget method works:
}  [...] 
} Except it doesn't accept the buffer.

Ah.  That's because triggering a sched event doesn't actually stop the
input read loop, so the accept-line won't be processed until the next
time there is actual input.

I suspect maybe the problem here is that you're going about this in
the wrong way to begin with.  Why is it important that the commands
be fed to ZLE and executed as if typed?

If I understand your desired end state correctly, I'd implement it
more like the following:

__convey_from_somwhere() {
    # Reschedule ourself ...
    sched -o +2 __convey_from_somwhere
    # Setup ...
    local commands
    __get_commands_from_somewhere

    # Ok, now we have the commands to run.  We want them recorded
    # in the history as if they were user input, so first do that.
    print -S "$commands"

    # Now just run them.  This assumes we're running from "sched -o"
    # (see above) which will handle saving/restoring ZLE state for
    # us in case any of these commands interact with the terminal.
    eval "${(j.;.)commands"
}

Re: Cannot use LBUFFER+= nor print -zr from zsh/sched call

[Sebastian Gniazdowski]

On 13 September 2016 at 18:55, Bart Schaefer <schaefer@brasslantern.com> wrote:
> If I understand your desired end state correctly, I'd implement it
> more like the following:
>
> __convey_from_somwhere() {
>     # Reschedule ourself ...
>     sched -o +2 __convey_from_somwhere
>     # Setup ...
>     local commands
>     __get_commands_from_somewhere
>
>     # Ok, now we have the commands to run.  We want them recorded
>     # in the history as if they were user input, so first do that.
>     print -S "$commands"
>
>     # Now just run them.  This assumes we're running from "sched -o"
>     # (see above) which will handle saving/restoring ZLE state for
>     # us in case any of these commands interact with the terminal.
>     eval "${(j.;.)commands"
> }

Nice trick with print -S, thanks. I had in mind the
execute-without-simulating-input and plan to include it as option. Am
quite afraid to run things without people's eyes. I think that this
will be good when user starts to trust Zconvey, and firstly I should
trust it, after it is ran for few months at users' boxes.

Best regards,
Sebastian Gniazdowski

Re: Cannot use LBUFFER+= nor print -zr from zsh/sched call

[Bart Schaefer]

On Sep 13,  7:29pm, Sebastian Gniazdowski wrote:
}
} Nice trick with print -S, thanks. I had in mind the
} execute-without-simulating-input and plan to include it as option. Am
} quite afraid to run things without people's eyes.

I find this statement puzzling, because if you do an accept-line from
inside the convey-handler, you're still potentially executing before
anyone sees the commands.  Making them visible during/after they've
executed isn't especially helpful if they're doing something they
shouldn't.

However, you can certainly accomplish displaying what's being done
without having to poke it into the editor buffer.  Minimally, you
can do (again using "sched -o")

    for histent in "$commands[@]"; do
      # sched -o will clean up zle for us, so fake a prompt ...
      print -Prn -- "$PS1"
      # ... show the command we're about to run ...
      print -r -- "$histent"
      # ... put it in the history ...
      print -Sr -- "$histent"
      # ... and then run it
      eval "$histent"
    done

This has to vary a little depending on the format of $commands (the
above presumes it's an array of one command per element) but you get
the idea.

Re: Cannot use LBUFFER+= nor print -zr from zsh/sched call

[Sebastian Gniazdowski]

On 14 September 2016 at 03:47, Bart Schaefer <schaefer@brasslantern.com> wrote:
> However, you can certainly accomplish displaying what's being done
> without having to poke it into the editor buffer.  Minimally, you
> can do (again using "sched -o")
>
>     for histent in "$commands[@]"; do
>       # sched -o will clean up zle for us, so fake a prompt ...
>       print -Prn -- "$PS1"
>       # ... show the command we're about to run ...
>       print -r -- "$histent"
>       # ... put it in the history ...
>       print -Sr -- "$histent"
>       # ... and then run it
>       eval "$histent"
>     done
>
> This has to vary a little depending on the format of $commands (the
> above presumes it's an array of one command per element) but you get
> the idea.

That's interesting. It would allow to do cool things like displaying
"STATUS: preparing to run; 5.. 4.. 3.. 2.. 1.. run!" with colors,
maybe other things, instead of simulating prompt. Could even use
zcurses and do some full screen pre-launch animation ;)

Best regards,
Sebastian Gniazdowski

Re: Cannot use LBUFFER+= nor print -zr from zsh/sched call

[Bart Schaefer]

On Sep 11, 11:28am, Sebastian Gniazdowski wrote:
}
}     zle .redisplay
}     zle .kill-buffer
}     LBUFFER+="${(j:; :)commands[@]}"
}     print -zr "${(j:; :)commands[@]}"
}     print -rl -- "${commands[@]}"
} 
} And command line isn't feed with the $commands.

Commands added with "sched" are handled in two different ways:  There
is one check just before the prompt is printed -- effectively at the
same time as the precmd function/hooks -- and then there is a check
each time the keyboard input loop finds that it has been sitting idle.
So a sched will never fire while you're rapidly typing something.

The reason LBUFFER seems not to work is because sched functions are not
ZLE widgets, and the ZLE buffer variables are only active during the
execution of a widget.

"print -zr ..." DOES work, but unless it happens during the pre-prompt
check the commands pushed onto the buffer stack will not be popped onto
the command line until the next time zle restarts (after some subsequent
prompt).

So what you need to do is make a widget for your sched command to run,
and then modify LBUFFER inside that widget (and call "zle redisplay"
to make the change be visible, or pass the -o option to sched, but not
both or you'll get extra blank lines printed).

Here's a completely useless example:

fiddle() { if zle; then zle fiddlewid; else print -zr "echo fiddled"; fi }
fiddlewid() { LBUFFER+="echo fiddled"; zle redisplay }
zle -N fiddlewid
sched +3 fiddle

Re: Cannot use LBUFFER+= nor print -zr from zsh/sched call

[Peter Stephenson]

On Sun, 11 Sep 2016 17:58:10 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Commands added with "sched" are handled in two different ways:  There
> is one check just before the prompt is printed -- effectively at the
> same time as the precmd function/hooks -- and then there is a check
> each time the keyboard input loop finds that it has been sitting idle.

I missed that second one in my reply yesterday, which is crucial for the
present context...

pws