* widget function must have zle codes @ 2023-08-18 0:11 Budi 2023-08-18 1:07 ` Bart Schaefer 0 siblings, 1 reply; 5+ messages in thread From: Budi @ 2023-08-18 0:11 UTC (permalink / raw) To: Zsh Users 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: widget function must have zle codes 2023-08-18 0:11 widget function must have zle codes Budi @ 2023-08-18 1:07 ` Bart Schaefer 2023-08-18 1:27 ` Budi 0 siblings, 1 reply; 5+ messages in thread From: Bart Schaefer @ 2023-08-18 1:07 UTC (permalink / raw) To: Budi; +Cc: Zsh Users 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: widget function must have zle codes 2023-08-18 1:07 ` Bart Schaefer @ 2023-08-18 1:27 ` Budi 2023-08-18 1:28 ` Budi 2023-08-18 4:42 ` Bart Schaefer 0 siblings, 2 replies; 5+ messages in thread From: Budi @ 2023-08-18 1:27 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zsh Users 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. > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: widget function must have zle codes 2023-08-18 1:27 ` Budi @ 2023-08-18 1:28 ` Budi 2023-08-18 4:42 ` Bart Schaefer 1 sibling, 0 replies; 5+ messages in thread From: Budi @ 2023-08-18 1:28 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zsh Users 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. >> > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: widget function must have zle codes 2023-08-18 1:27 ` Budi 2023-08-18 1:28 ` Budi @ 2023-08-18 4:42 ` Bart Schaefer 1 sibling, 0 replies; 5+ messages in thread From: Bart Schaefer @ 2023-08-18 4:42 UTC (permalink / raw) To: Budi; +Cc: Zsh Users 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-08-18 4:43 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-08-18 0:11 widget function must have zle codes Budi 2023-08-18 1:07 ` Bart Schaefer 2023-08-18 1:27 ` Budi 2023-08-18 1:28 ` Budi 2023-08-18 4:42 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).