widget function must have zle codes

widget function must have zle codes

[Budi]

How can;t this work
a widget function having zle codes

functions[t]="zle -I; \e[H   2>/dev/null echo Test preceding word"



t:1: bad pattern: e[H


Please make it \e[F, \e[A, and all others works as good as in zle
bindkey -s,   help.

Re: widget function must have zle codes

[Bart Schaefer]

On Thu, Aug 17, 2023 at 5:11 PM Budi <budikusasi@gmail.com> wrote:
>
> How can;t this work
> a widget function having zle codes

I'm not entirely sure what you're attempting to accomplish here.

> t:1: bad pattern: e[H

You're getting that specific error because you haven't quoted the
string properly, but I don't think it would do what you want anyway.
It looks like you're trying to extrapolate Roman's "bind-x" example to
a case it wasn't meant to cover.  One would not normally create a
widget by assigning to the functions[] array, Roman did that
specifically in order to construct a new function body from the values
in the positional parameters of the "bind-x" function.

Further, it's the "zle -N" command that creates a widget, the function
is the widget implementation.  Neither of them works without the
other.

In ZLE widgets, you don't normally refer to an action by it's key
binding, instead you refer to it by its widget name, and use the "zle"
command to run it.  So instead of $'\e[H' (which would be the correct
quoting you were after), you would write
   zle beginning-of-line
(or whatever action you wanted).  Each built-in widget has a special
name starting with a "." that you can use to avoid calling some
user-defined replacement implementation, so you might see examples
like
  zle .beginning-of-line

> functions[t]="zle -I; \e[H   2>/dev/null echo Test preceding word"

I can't tell what you're expecting to have happen with that "echo".
If you meant for "Test preceding word" to become part of the line
being edited, you need to assign that to one of the BUFFER, LBUFFER,
or RBUFFER variables (please see the doc).

I strongly suggest you look at some of the examples in Functions/Zle/
in the distribution.  Many are a bit esoteric but most have extensive
explanatory comments.  The easiest to understand might be
  Functions/Zle/history-search-end
  Functions/Zle/down-line-or-beginning-search
  Functions/Zle/up-line-or-beginning-search
Note these files are function bodies only, they expect to be turned
into actual widgets by (for example)
  autoload history-search-end
  Zle -N history-search-end

There's also
  Functions/Zle/vi-pipe
but note that its setup commentary forgot to mention the "zle -N vi-pipe" part.

Re: widget function must have zle codes

[Budi]

original simpe aim,
to nullify any std output in bind -s, (Bash bind-x default)



bindkey -s "^m" "\e[H   2>/dev/null [[ $- =~ x ]]&&{ set +x;echo Trace
OFF ;} ||{ set -x;echo Trace ON;};print -s '\e[F'\r\e[A"


How is the precise correct one ?


On 8/18/23, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Thu, Aug 17, 2023 at 5:11 PM Budi <budikusasi@gmail.com> wrote:
>>
>> How can;t this work
>> a widget function having zle codes
>
> I'm not entirely sure what you're attempting to accomplish here.
>
>> t:1: bad pattern: e[H
>
> You're getting that specific error because you haven't quoted the
> string properly, but I don't think it would do what you want anyway.
> It looks like you're trying to extrapolate Roman's "bind-x" example to
> a case it wasn't meant to cover.  One would not normally create a
> widget by assigning to the functions[] array, Roman did that
> specifically in order to construct a new function body from the values
> in the positional parameters of the "bind-x" function.
>
> Further, it's the "zle -N" command that creates a widget, the function
> is the widget implementation.  Neither of them works without the
> other.
>
> In ZLE widgets, you don't normally refer to an action by it's key
> binding, instead you refer to it by its widget name, and use the "zle"
> command to run it.  So instead of $'\e[H' (which would be the correct
> quoting you were after), you would write
>    zle beginning-of-line
> (or whatever action you wanted).  Each built-in widget has a special
> name starting with a "." that you can use to avoid calling some
> user-defined replacement implementation, so you might see examples
> like
>   zle .beginning-of-line
>
>> functions[t]="zle -I; \e[H   2>/dev/null echo Test preceding word"
>
> I can't tell what you're expecting to have happen with that "echo".
> If you meant for "Test preceding word" to become part of the line
> being edited, you need to assign that to one of the BUFFER, LBUFFER,
> or RBUFFER variables (please see the doc).
>
> I strongly suggest you look at some of the examples in Functions/Zle/
> in the distribution.  Many are a bit esoteric but most have extensive
> explanatory comments.  The easiest to understand might be
>   Functions/Zle/history-search-end
>   Functions/Zle/down-line-or-beginning-search
>   Functions/Zle/up-line-or-beginning-search
> Note these files are function bodies only, they expect to be turned
> into actual widgets by (for example)
>   autoload history-search-end
>   Zle -N history-search-end
>
> There's also
>   Functions/Zle/vi-pipe
> but note that its setup commentary forgot to mention the "zle -N vi-pipe"
> part.
>

Re: widget function must have zle codes

[Budi]

original simpe aim:
to nullify any std output in bind -s, (Bash bind-x default)



bindkey -s "^m" "\e[H   2>/dev/null [[ $- =~ x ]]&&{ set +x;echo Trace
OFF ;} ||{ set -x;echo Trace ON;};print -s '\e[F'\r\e[A"


How is the precise correct one ?

On 8/18/23, Budi <budikusasi@gmail.com> wrote:
> original simpe aim,
> to nullify any std output in bind -s, (Bash bind-x default)
>
>
>
> bindkey -s "^m" "\e[H   2>/dev/null [[ $- =~ x ]]&&{ set +x;echo Trace
> OFF ;} ||{ set -x;echo Trace ON;};print -s '\e[F'\r\e[A"
>
>
> How is the precise correct one ?
>
>
> On 8/18/23, Bart Schaefer <schaefer@brasslantern.com> wrote:
>> On Thu, Aug 17, 2023 at 5:11 PM Budi <budikusasi@gmail.com> wrote:
>>>
>>> How can;t this work
>>> a widget function having zle codes
>>
>> I'm not entirely sure what you're attempting to accomplish here.
>>
>>> t:1: bad pattern: e[H
>>
>> You're getting that specific error because you haven't quoted the
>> string properly, but I don't think it would do what you want anyway.
>> It looks like you're trying to extrapolate Roman's "bind-x" example to
>> a case it wasn't meant to cover.  One would not normally create a
>> widget by assigning to the functions[] array, Roman did that
>> specifically in order to construct a new function body from the values
>> in the positional parameters of the "bind-x" function.
>>
>> Further, it's the "zle -N" command that creates a widget, the function
>> is the widget implementation.  Neither of them works without the
>> other.
>>
>> In ZLE widgets, you don't normally refer to an action by it's key
>> binding, instead you refer to it by its widget name, and use the "zle"
>> command to run it.  So instead of $'\e[H' (which would be the correct
>> quoting you were after), you would write
>>    zle beginning-of-line
>> (or whatever action you wanted).  Each built-in widget has a special
>> name starting with a "." that you can use to avoid calling some
>> user-defined replacement implementation, so you might see examples
>> like
>>   zle .beginning-of-line
>>
>>> functions[t]="zle -I; \e[H   2>/dev/null echo Test preceding word"
>>
>> I can't tell what you're expecting to have happen with that "echo".
>> If you meant for "Test preceding word" to become part of the line
>> being edited, you need to assign that to one of the BUFFER, LBUFFER,
>> or RBUFFER variables (please see the doc).
>>
>> I strongly suggest you look at some of the examples in Functions/Zle/
>> in the distribution.  Many are a bit esoteric but most have extensive
>> explanatory comments.  The easiest to understand might be
>>   Functions/Zle/history-search-end
>>   Functions/Zle/down-line-or-beginning-search
>>   Functions/Zle/up-line-or-beginning-search
>> Note these files are function bodies only, they expect to be turned
>> into actual widgets by (for example)
>>   autoload history-search-end
>>   Zle -N history-search-end
>>
>> There's also
>>   Functions/Zle/vi-pipe
>> but note that its setup commentary forgot to mention the "zle -N vi-pipe"
>> part.
>>
>

Re: widget function must have zle codes

[Bart Schaefer]

On Thu, Aug 17, 2023 at 6:27 PM Budi <budikusasi@gmail.com> wrote:
>
> bindkey -s "^m" "\e[H   2>/dev/null [[ $- =~ x ]]&&{ set +x;echo Trace
> OFF ;} ||{ set -x;echo Trace ON;};print -s '\e[F'\r\e[A"

To the best of my ability to interpret that ... literally:

binding-for-ctrl-m () {
  zle .beginning-of-line
  zle -I
  {
  if [[ -o xtrace ]]; then
    { set +x; echo Trace OFF }
  else
    { set -x; echo Trace ON }
  fi
  zle .end-of-line
  zle .accept-and-hold
  } 2>/dev/null
}
zle -N binding-for-ctrl-m
bindkey ^m binding-for-ctrl-m

This "works" but there's a problem not of your making:  ZLE widgets
are not allowed to change the global setting of XTRACE -- it is always
saved on entry to ZLE and restored again on exit -- so the set -x or
+x in the widget is useless.

Before I fix that, let me point out that the beginning/end-of-line
motions are not needed, I included them just to translate as closely
as possible.  Even with bind -x in bash the \e[H is not needed; I'm
not sure about the \e[F.  The "zle -I" is what tells zle that some
other output is coming, so it should get out of the way and then
repaint when it gets control again.  bind -x does that too, at least
in some simple experiments.

To avoid the XTRACE problem, if I'm following correctly what you
expect the \e[F\r\e[A part to accomplish, the shortest solution is
probably:

binding-for-ctrl-m() {
  zle -I
  print Trace ON
  eval "() { setopt localoptions xtrace; $BUFFER }"
  print Trace OFF
}

If you actually require the set -x to take global effect but be
invisible to the history etc., it gets a lot more complicated, so I
won't go there yet.

As a last note, "print -s" writes to the history list, not to the
editor, so you would never use that for editor control keystrokes.  If
you really need to send the key binding for an action instead of
calling it with "zle widget-name", that's what "zle -U" is for, but
anything sent that way is not looked at until the current widget
returns.