zsh-users
 help / color / mirror / code / Atom feed
* prevent some lines directly coming from the history from being executed
@ 2022-05-24 15:47 Vincent Lefevre
  2022-05-24 18:58 ` Bart Schaefer
  0 siblings, 1 reply; 23+ messages in thread
From: Vincent Lefevre @ 2022-05-24 15:47 UTC (permalink / raw)
  To: zsh-users

Hi,

Some lines coming from the history may be "dangerous", in the sense
that one may not want to executed them by mistake (e.g. for lines
recalled with a quick Ctrl-R ... [Return]).

Is there some mechanism to prevent such lines from being executed if
they were not modified after recalling them from the history? E.g.
something like a hook that would inspect such lines and return 0 or 1,
depending on what one wants to do.

Note: I do not want to blacklist such lines from the history.
That is, such lines should still be there in the history to make
sense, but they need some kind of confirmation before execution.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-24 15:47 prevent some lines directly coming from the history from being executed Vincent Lefevre
@ 2022-05-24 18:58 ` Bart Schaefer
  2022-05-25  2:54   ` Vincent Lefevre
  0 siblings, 1 reply; 23+ messages in thread
From: Bart Schaefer @ 2022-05-24 18:58 UTC (permalink / raw)
  To: Zsh Users

On Tue, May 24, 2022 at 8:47 AM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> Some lines coming from the history may be "dangerous", in the sense
> that one may not want to executed them by mistake (e.g. for lines
> recalled with a quick Ctrl-R ... [Return]).
>
> Is there some mechanism to prevent such lines from being executed if
> they were not modified after recalling them from the history?

The first question is, how do you identify those lines?  Pattern match?

> something like a hook that would inspect such lines and return 0 or 1,
> depending on what one wants to do.

You can add something to zle-line-finish() that compares
[[ $BUFFER = ${history[$HISTNO]} ]]
along with whatever your other criteria are.  This will always be
false for a new command line, and I believe should always be true for
an unedited line retrieved from history, but might need tweaking for
multi-line constructs.


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-24 18:58 ` Bart Schaefer
@ 2022-05-25  2:54   ` Vincent Lefevre
  2022-05-25  3:59     ` Bart Schaefer
  0 siblings, 1 reply; 23+ messages in thread
From: Vincent Lefevre @ 2022-05-25  2:54 UTC (permalink / raw)
  To: zsh-users

On 2022-05-24 11:58:04 -0700, Bart Schaefer wrote:
> On Tue, May 24, 2022 at 8:47 AM Vincent Lefevre <vincent@vinc17.net> wrote:
> >
> > Some lines coming from the history may be "dangerous", in the sense
> > that one may not want to executed them by mistake (e.g. for lines
> > recalled with a quick Ctrl-R ... [Return]).
> >
> > Is there some mechanism to prevent such lines from being executed if
> > they were not modified after recalling them from the history?
> 
> The first question is, how do you identify those lines?  Pattern match?

Yes.

> > something like a hook that would inspect such lines and return 0 or 1,
> > depending on what one wants to do.
> 
> You can add something to zle-line-finish() that compares
> [[ $BUFFER = ${history[$HISTNO]} ]]
> along with whatever your other criteria are.  This will always be
> false for a new command line, and I believe should always be true for
> an unedited line retrieved from history, but might need tweaking for
> multi-line constructs.

This doesn't seem to work. I've added

  [[ $BUFFER = ${history[$HISTNO]} ]]

at the end (thus currently catching all unmodified lines), but
this doesn't change anything. Is the exit status of the function
really taken into account to prevent the execution?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-25  2:54   ` Vincent Lefevre
@ 2022-05-25  3:59     ` Bart Schaefer
  2022-05-25  8:49       ` Vincent Lefevre
  0 siblings, 1 reply; 23+ messages in thread
From: Bart Schaefer @ 2022-05-25  3:59 UTC (permalink / raw)
  To: Zsh Users

On Tue, May 24, 2022 at 7:54 PM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> On 2022-05-24 11:58:04 -0700, Bart Schaefer wrote:
\> >
> > You can add something to zle-line-finish() that compares
> > [[ $BUFFER = ${history[$HISTNO]} ]]
> > along with whatever your other criteria are.
>
> This doesn't seem to work. [...]
> Is the exit status of the function
> really taken into account to prevent the execution?

Sorry, I didn't mean to imply that was ALL you needed to do.

zle-line-finish() {
  if [[ $BUFFER = ${history[$HISTNO]} ]]; then
    local confirm
    read -q confirm"?Confirm: $BUFFER ?"
    [[ $confirm = y ]] || BUFFER=""
  fi
}

Or something that expands upon that.


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-25  3:59     ` Bart Schaefer
@ 2022-05-25  8:49       ` Vincent Lefevre
  2022-05-26  1:25         ` Bart Schaefer
  0 siblings, 1 reply; 23+ messages in thread
From: Vincent Lefevre @ 2022-05-25  8:49 UTC (permalink / raw)
  To: zsh-users

On 2022-05-24 20:59:53 -0700, Bart Schaefer wrote:
> zle-line-finish() {
>   if [[ $BUFFER = ${history[$HISTNO]} ]]; then
>     local confirm
>     read -q confirm"?Confirm: $BUFFER ?"
>     [[ $confirm = y ]] || BUFFER=""
>   fi
> }

There are some display issues in some cases due to the "Confirm"...
Instead, if the condition is met, is it possible to remain in ZLE
with the current buffer, as if I didn't do accept-line?
(I could set a psvar element so that I could change the prompt to
indicate that this needs confirmation.)

Or perhaps I could change the bindings to use a wrapper around
accept-line (ditto for accept-line-and-down-history).

Something like that (to be completed with pattern matching):

zle -A accept-line real-accept-line

accept-line-wrapper() {
  if [[ -z $psvar[3] && $BUFFER = ${history[$HISTNO]} ]]; then
    psvar[3]="[Confirm]"
    zle reset-prompt
  else
    psvar[3]=""
    zle real-accept-line
  fi
}

zle -N accept-line accept-line-wrapper

where $PS1 contains "%3v", and with psvar[3]="" in precmd().

Could there be any issue? Or is there anything to add?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-25  8:49       ` Vincent Lefevre
@ 2022-05-26  1:25         ` Bart Schaefer
  2022-05-26 14:36           ` Vincent Lefevre
  0 siblings, 1 reply; 23+ messages in thread
From: Bart Schaefer @ 2022-05-26  1:25 UTC (permalink / raw)
  To: Zsh Users

On Wed, May 25, 2022 at 1:49 AM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> There are some display issues in some cases due to the "Confirm"...

Probably the same underlying issue as I recently reported with zle -M ... but
  read -q confirm$'?\nConfirm? '
might work more consistently.

> Instead, if the condition is met, is it possible to remain in ZLE
> with the current buffer, as if I didn't do accept-line?
[...]
> Or perhaps I could change the bindings to use a wrapper around
> accept-line (ditto for accept-line-and-down-history).

Yes, this could be done as a wrapper.  If you want to try to keep it
in zle-line-finish, replace
  ... || BUFFER=""
with
  ... || { print -z $BUFFER && BUFFER="" }
or similar.

> zle -A accept-line real-accept-line

There's the built-in ".accept-line" widget for this sort of thing, so
you don't have to create a new alias.

> zle -N accept-line accept-line-wrapper
>
> where $PS1 contains "%3v", and with psvar[3]="" in precmd().
>
> Could there be any issue? Or is there anything to add?

I don't see any particular problem with that approach.


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-26  1:25         ` Bart Schaefer
@ 2022-05-26 14:36           ` Vincent Lefevre
  2022-05-26 15:53             ` Daniel Shahaf
  2022-05-26 16:37             ` Bart Schaefer
  0 siblings, 2 replies; 23+ messages in thread
From: Vincent Lefevre @ 2022-05-26 14:36 UTC (permalink / raw)
  To: zsh-users

On 2022-05-25 18:25:40 -0700, Bart Schaefer wrote:
> On Wed, May 25, 2022 at 1:49 AM Vincent Lefevre <vincent@vinc17.net> wrote:
> > There are some display issues in some cases due to the "Confirm"...
> 
> Probably the same underlying issue as I recently reported with zle -M ... but
>   read -q confirm$'?\nConfirm? '
> might work more consistently.

Yes, it seems so.

> > Instead, if the condition is met, is it possible to remain in ZLE
> > with the current buffer, as if I didn't do accept-line?
> [...]
> > Or perhaps I could change the bindings to use a wrapper around
> > accept-line (ditto for accept-line-and-down-history).
> 
> Yes, this could be done as a wrapper.  If you want to try to keep it
> in zle-line-finish, replace
>   ... || BUFFER=""
> with
>   ... || { print -z $BUFFER && BUFFER="" }
> or similar.

But this has the effect to duplicate the line in the terminal.
For instance:

zira:~> echo foo                                                      <16:29:05
zira:~> echo foo                                                      <16:29:09
foo

> > zle -A accept-line real-accept-line
> 
> There's the built-in ".accept-line" widget for this sort of thing, so
> you don't have to create a new alias.

Is this documented?

When searching the man pages, I could find only one place where
such a built-in is used: in the example for recursive-edit.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-26 14:36           ` Vincent Lefevre
@ 2022-05-26 15:53             ` Daniel Shahaf
  2022-05-26 16:13               ` Peter Stephenson
  2022-05-26 16:37             ` Bart Schaefer
  1 sibling, 1 reply; 23+ messages in thread
From: Daniel Shahaf @ 2022-05-26 15:53 UTC (permalink / raw)
  To: Vincent Lefevre; +Cc: zsh-users

Vincent Lefevre wrote on Thu, May 26, 2022 at 16:36:02 +0200:
> On 2022-05-25 18:25:40 -0700, Bart Schaefer wrote:
> > On Wed, May 25, 2022 at 1:49 AM Vincent Lefevre <vincent@vinc17.net> wrote:
> > > zle -A accept-line real-accept-line
> > 
> > There's the built-in ".accept-line" widget for this sort of thing, so
> > you don't have to create a new alias.
> 
> Is this documented?
> 
> When searching the man pages, I could find only one place where
> such a built-in is used: in the example for recursive-edit.

There's this in compsys.yo:

> Should you need to use the original completion commands, you can still
> bind keys to the old widgets by putting a `tt(.)' in front of the
> widget name, e.g. `tt(.expand-or-complete)'.

And this in mod_complist.yo:

> All movement functions wrap around at the edges; any other zle function not
> listed leaves menu selection and executes that function.  It is possible to
> make widgets in the above list do the same by using the form of the widget
> with a `tt(.)' in front.  For example, the widget `tt(.accept-line)' has
> the effect of leaving menu selection and accepting the entire command line.

but, yes, it should be mentioned in the zle documentation too, not only
in the compsys documentation.

Anyone volunteering to write the patch?

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-26 15:53             ` Daniel Shahaf
@ 2022-05-26 16:13               ` Peter Stephenson
  2022-05-27 12:40                 ` Daniel Shahaf
  0 siblings, 1 reply; 23+ messages in thread
From: Peter Stephenson @ 2022-05-26 16:13 UTC (permalink / raw)
  To: zsh-users


> On 26 May 2022 at 16:53 Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Vincent Lefevre wrote on Thu, May 26, 2022 at 16:36:02 +0200:
> > On 2022-05-25 18:25:40 -0700, Bart Schaefer wrote:
> > > On Wed, May 25, 2022 at 1:49 AM Vincent Lefevre <vincent@vinc17.net> wrote:
> > > > zle -A accept-line real-accept-line
> > > 
> > > There's the built-in ".accept-line" widget for this sort of thing, so
> > > you don't have to create a new alias.
> > 
> > Is this documented?
> > 
> > When searching the man pages, I could find only one place where
> > such a built-in is used: in the example for recursive-edit.
>...
> but, yes, it should be mentioned in the zle documentation too, not only
> in the compsys documentation.
> 
> Anyone volunteering to write the patch?

zle.yo contains the following.  We don't have the actual names for
all the widgets, which makes them hard to search for, but the actual
rule is very simple once you know it.  So while this isn't ideal I'm
not sure what we'd want to change.  Should we put some examples here of
the cases you're most likely to use, in particular .accept-line?

pws

The standard widgets built into ZLE are listed in
ifzman(the section `Standard Widgets' below)\
ifnzman(noderef(Standard Widgets)).
Other built-in widgets can be defined by other modules (see
ifzman(zmanref(zshmodules))\
ifnzman(noderef(Zsh Modules))\
).  Each built-in widget has two names: its normal canonical name, and the
same name preceded by a `tt(.)'.  The `tt(.)' name is special: it can't be
rebound to a different widget.  This makes the widget available even when
its usual name has been redefined.


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-26 14:36           ` Vincent Lefevre
  2022-05-26 15:53             ` Daniel Shahaf
@ 2022-05-26 16:37             ` Bart Schaefer
  1 sibling, 0 replies; 23+ messages in thread
From: Bart Schaefer @ 2022-05-26 16:37 UTC (permalink / raw)
  To: Zsh Users

On Thu, May 26, 2022 at 7:36 AM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> On 2022-05-25 18:25:40 -0700, Bart Schaefer wrote:
> > Yes, this could be done as a wrapper.  If you want to try to keep it
> > in zle-line-finish, replace
> >   ... || BUFFER=""
> > with
> >   ... || { print -z $BUFFER && BUFFER="" }
> > or similar.
>
> But this has the effect to duplicate the line in the terminal.

Well, yes, but I was presuming the "Confirm? " prompt would appear
between the two.


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-26 16:13               ` Peter Stephenson
@ 2022-05-27 12:40                 ` Daniel Shahaf
  2022-05-28  0:07                   ` Vincent Lefevre
  0 siblings, 1 reply; 23+ messages in thread
From: Daniel Shahaf @ 2022-05-27 12:40 UTC (permalink / raw)
  To: zsh-users, Vincent Lefevre

Peter Stephenson wrote on Thu, 26 May 2022 16:13 +00:00:
>> On 26 May 2022 at 16:53 Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>> Vincent Lefevre wrote on Thu, May 26, 2022 at 16:36:02 +0200:
>> > On 2022-05-25 18:25:40 -0700, Bart Schaefer wrote:
>> > > On Wed, May 25, 2022 at 1:49 AM Vincent Lefevre <vincent@vinc17.net> wrote:
>> > > > zle -A accept-line real-accept-line
>> > > 
>> > > There's the built-in ".accept-line" widget for this sort of thing, so
>> > > you don't have to create a new alias.
>> > 
>> > Is this documented?
>> > 
>> > When searching the man pages, I could find only one place where
>> > such a built-in is used: in the example for recursive-edit.
>>...
>> but, yes, it should be mentioned in the zle documentation too, not only
>> in the compsys documentation.
>> 
>> Anyone volunteering to write the patch?
>
> zle.yo contains the following.  We don't have the actual names for
> all the widgets, which makes them hard to search for, but the actual
> rule is very simple once you know it.  So while this isn't ideal I'm
> not sure what we'd want to change.  Should we put some examples here of
> the cases you're most likely to use, in particular .accept-line?

Thanks.

I expected there'd be an instance of «tt(.)var(widget)», and that's what
I initially grepped for.

Vincent, what did you search the man pages for?

Cheers,

Daniel

> pws
>
> The standard widgets built into ZLE are listed in
> ifzman(the section `Standard Widgets' below)\
> ifnzman(noderef(Standard Widgets)).
> Other built-in widgets can be defined by other modules (see
> ifzman(zmanref(zshmodules))\
> ifnzman(noderef(Zsh Modules))\
> ).  Each built-in widget has two names: its normal canonical name, and the
> same name preceded by a `tt(.)'.  The `tt(.)' name is special: it can't be
> rebound to a different widget.  This makes the widget available even when
> its usual name has been redefined.


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-27 12:40                 ` Daniel Shahaf
@ 2022-05-28  0:07                   ` Vincent Lefevre
  2022-05-28 10:06                     ` Daniel Shahaf
  0 siblings, 1 reply; 23+ messages in thread
From: Vincent Lefevre @ 2022-05-28  0:07 UTC (permalink / raw)
  To: zsh-users

On 2022-05-27 12:40:32 +0000, Daniel Shahaf wrote:
> Peter Stephenson wrote on Thu, 26 May 2022 16:13 +00:00:
> >> On 26 May 2022 at 16:53 Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >> Vincent Lefevre wrote on Thu, May 26, 2022 at 16:36:02 +0200:
> >> > When searching the man pages, I could find only one place where
> >> > such a built-in is used: in the example for recursive-edit.
> >>...
> >> but, yes, it should be mentioned in the zle documentation too, not only
> >> in the compsys documentation.
> >> 
> >> Anyone volunteering to write the patch?
> >
> > zle.yo contains the following.  We don't have the actual names for
> > all the widgets, which makes them hard to search for, but the actual
> > rule is very simple once you know it.  So while this isn't ideal I'm
> > not sure what we'd want to change.

This is in Section "ZLE WIDGETS". But since this is specific to
the standard widgets, shouldn't this be also at the beginning of
Section "STANDARD WIDGETS"?

> > Should we put some examples here of the cases you're most likely
> > to use, in particular .accept-line?

This would be interesting for users who wish to control the line
before it is accepted.

> Thanks.
> 
> I expected there'd be an instance of «tt(.)var(widget)», and that's what
> I initially grepped for.
> 
> Vincent, what did you search the man pages for?

I had searched for " \.[a-z]". I wasn't expecting quotes (it seems
that most often, quotes are not used for single words).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-28  0:07                   ` Vincent Lefevre
@ 2022-05-28 10:06                     ` Daniel Shahaf
  2022-05-28 18:43                       ` Bart Schaefer
  2022-05-30  9:02                       ` Vincent Lefevre
  0 siblings, 2 replies; 23+ messages in thread
From: Daniel Shahaf @ 2022-05-28 10:06 UTC (permalink / raw)
  To: zsh-users

Vincent Lefevre wrote on Sat, May 28, 2022 at 02:07:20 +0200:
> On 2022-05-27 12:40:32 +0000, Daniel Shahaf wrote:
> > Peter Stephenson wrote on Thu, 26 May 2022 16:13 +00:00:
> > >> On 26 May 2022 at 16:53 Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > >> Vincent Lefevre wrote on Thu, May 26, 2022 at 16:36:02 +0200:
> > >> > When searching the man pages, I could find only one place where
> > >> > such a built-in is used: in the example for recursive-edit.
> > >>...
> > >> but, yes, it should be mentioned in the zle documentation too, not only
> > >> in the compsys documentation.
> > >> 
> > >> Anyone volunteering to write the patch?
> > >
> > > zle.yo contains the following.  We don't have the actual names for
> > > all the widgets, which makes them hard to search for, but the actual
> > > rule is very simple once you know it.  So while this isn't ideal I'm
> > > not sure what we'd want to change.
> 
> This is in Section "ZLE WIDGETS". But since this is specific to
> the standard widgets, shouldn't this be also at the beginning of
> Section "STANDARD WIDGETS"?
> 

The next paragraph recommends that user-defined widgets not be named
with leading dots.  That wouldn't belong under "Standard widgets".

> > > Should we put some examples here of the cases you're most likely
> > > to use, in particular .accept-line?
> 
> This would be interesting for users who wish to control the line
> before it is accepted.
> 
> > Thanks.
> > 
> > I expected there'd be an instance of «tt(.)var(widget)», and that's what
> > I initially grepped for.
> > 
> > Vincent, what did you search the man pages for?
> 
> I had searched for " \.[a-z]". I wasn't expecting quotes (it seems
> that most often, quotes are not used for single words).

There's no shortage of tt() instances surrounded by `TeX quotes',
though.

How about the following?  I think the new text has a lot of room for
improvement, so feedback's very welcome.

Cheers,

Daniel

diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo
index 2d033a0a1..ce20513b8 100644
--- a/Doc/Zsh/zle.yo
+++ b/Doc/Zsh/zle.yo
@@ -746,17 +746,42 @@ ifnzman(noderef(Standard Widgets)).
 Other built-in widgets can be defined by other modules (see
 ifzman(zmanref(zshmodules))\
 ifnzman(noderef(Zsh Modules))\
-).  Each built-in widget has two names: its normal canonical name, and the
-same name preceded by a `tt(.)'.  The `tt(.)' name is special: it can't be
-rebound to a different widget.  This makes the widget available even when
-its usual name has been redefined.
+).
 
 User-defined widgets are defined using `tt(zle -N)', and implemented
 as shell functions.  When the widget is executed, the corresponding
 shell function is executed, and can perform editing (or other) actions.
-It is recommended that user-defined widgets should not have names
+
+cindex(widgets, shadowing standard)
+User-defined widgets may shadow (replace) standard widgets: for instance,
+after `tt(zle -N self-insert myfunc)', any invocation of the standard
+tt(self-insert) widget (including every keypress that appends an alphanumeric
+or space character to the command line) would invoke the user-defined
+function tt(myfunc) rather than the standard implementation of that widget.
+However, each standard widget `var(foo)' is also available under the
+name `tt(.)var(foo)', and this name can't be rebound to a different widget.
+This makes the standard widget available to be called or bound even when
+its usual name has been redefined.
+Therefore, for forward compatibility with future versions of the shell,
+it is recommended that user-defined widgets should not have names
 starting with `tt(.)'.
 
+Continuing the example, tt(myfunc) would typically invoke the built-in widget
+it is replacing using the dot-prefix syntax:
+
+example(zle -N self-insert myfunc
+myfunc+LPAR()+RPAR() {
+  [[ $KEYS == [aeiou] ]] && zle .self-insert -- "$@"
+  zle .self-insert -- "$@" 
+})
+
+This example causes vowels to be inserted twice.
+
+Note the use of the dot-prefix syntax.  If the tt(self-insert) widget had been
+invoked without the dot DASH()- that is, as `tt(zle self-insert -- "$@")' DASH()-
+then tt(myfunc) would have been called again, effecting a bottomless
+recursion.
+
 texinode(User-Defined Widgets)(Standard Widgets)(Zle Widgets)(Zsh Line Editor)
 sect(User-Defined Widgets)
 cindex(widgets, user-defined)


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-28 10:06                     ` Daniel Shahaf
@ 2022-05-28 18:43                       ` Bart Schaefer
  2022-05-29 22:55                         ` Daniel Shahaf
  2022-05-30  9:02                       ` Vincent Lefevre
  1 sibling, 1 reply; 23+ messages in thread
From: Bart Schaefer @ 2022-05-28 18:43 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh Users

On Sat, May 28, 2022 at 3:06 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> How about the following?  I think the new text has a lot of room for
> improvement, so feedback's very welcome.

Generally very good.  Just a couple of thoughts:

> +cindex(widgets, shadowing standard)

"Shadow(ing)" is not a term I'd think to search for in this context.
Wrap, override, overload, replace, re-implement, ...?

> +However, each standard widget `var(foo)' is also available under the
> +name `tt(.)var(foo)', and this name can't be rebound to a different widget.

I would probably have used something like var(std) or even
var(stdwidg) here, but that's a nit.

> +Therefore, for forward compatibility with future versions of the shell,
> +it is recommended that user-defined widgets should not have names
>  starting with `tt(.)'.

It's actually prohibited to name a user-defined widget the same as one
of the reserved dot-names, so this recommendation could be more
specific.

> +then tt(myfunc) would have been called again, effecting a bottomless
> +recursion.

Perhaps my old-fogey-ness (or USA-centrism) is showing, but I've never
seen the word "bottomless" used in this context before, only
"infinite" or more rarely "endless".  Another nit, as it doesn't
really change the clarity, just mentioning because I found it curious.


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-28 18:43                       ` Bart Schaefer
@ 2022-05-29 22:55                         ` Daniel Shahaf
  2022-05-30  4:04                           ` Bart Schaefer
  0 siblings, 1 reply; 23+ messages in thread
From: Daniel Shahaf @ 2022-05-29 22:55 UTC (permalink / raw)
  To: Zsh Users

[-- Attachment #1: Type: text/plain, Size: 2763 bytes --]

Bart Schaefer wrote on Sat, 28 May 2022 18:43 +00:00:
> On Sat, May 28, 2022 at 3:06 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>> +cindex(widgets, shadowing standard)
>
> "Shadow(ing)" is not a term I'd think to search for in this context.
> Wrap, override, overload, replace, re-implement, ...?
>

Most of these terms imply particular semantics (e.g., "wrap" implies the
new definition calls the old one).  I think "shadow" is the right term
here, so how about:

+cindex(widgets, shadowing standard)
+cindex(widgets, overriding standard)
+User-defined widgets may shadow (override) standard widgets: for instance,

>> +However, each standard widget `var(foo)' is also available under the
>> +name `tt(.)var(foo)', and this name can't be rebound to a different widget.
>
> I would probably have used something like var(std) or even
> var(stdwidg) here, but that's a nit.
>

Personally I find it easier to read with "foo", but I suppose that's
a matter of taste.  I'll write it whichever way is the house style.

>> +Therefore, for forward compatibility with future versions of the shell,
>> +it is recommended that user-defined widgets should not have names
>>  starting with `tt(.)'.
>
> It's actually prohibited to name a user-defined widget the same as one
> of the reserved dot-names, so this recommendation could be more
> specific.
>

OK, can spell out the problem.  Wouldn't that make the paragraph a bit
of a wall of text, though?  Also, it would further break the flow
(example, recommendation, rationale of the recommendation, continuation
of example).  That flow was one of the things that I wasn't happy about
regarding the v1 of the patch.

+Therefore, for forward compatibility with future versions of the shell,
+it is recommended that user-defined widgets should not have names
-starting with `tt(.)'.
+starting with `tt(.)'.  (If a user-defined widget is named `tt(.)var(some-name)'
+and a future version of the shell introduces a built-in `var(some-name)' widget,
+the user-defined widget's definition will raise an error under that future
+version of the shell.)

>> +then tt(myfunc) would have been called again, effecting a bottomless
>> +recursion.
>
> Perhaps my old-fogey-ness (or USA-centrism) is showing, but I've never
> seen the word "bottomless" used in this context before, only
> "infinite" or more rarely "endless".  Another nit, as it doesn't
> really change the clarity, just mentioning because I found it curious.

Prior art:

(1995) https://github.com/freebsd/freebsd-src/commit/cd02a0b741846be432ea4646890e617c8c3b445d

(2003) https://www.freebsd.org/cgi/man.cgi?query=exit&apropos=0&sektion=3&manpath=FreeBSD+5.0-RELEASE&arch=default&format=html

It does seem to be rather rare, though.

Thanks for the review!

Daniel

[-- Attachment #2: v2.txt --]
[-- Type: text/plain, Size: 2622 bytes --]

--- a/Doc/Zsh/zle.yo
+++ b/Doc/Zsh/zle.yo
@@ -746,17 +746,46 @@ ifnzman(noderef(Standard Widgets)).
 Other built-in widgets can be defined by other modules (see
 ifzman(zmanref(zshmodules))\
 ifnzman(noderef(Zsh Modules))\
-).  Each built-in widget has two names: its normal canonical name, and the
-same name preceded by a `tt(.)'.  The `tt(.)' name is special: it can't be
-rebound to a different widget.  This makes the widget available even when
-its usual name has been redefined.
+).
 
 User-defined widgets are defined using `tt(zle -N)', and implemented
 as shell functions.  When the widget is executed, the corresponding
 shell function is executed, and can perform editing (or other) actions.
-It is recommended that user-defined widgets should not have names
+
+cindex(widgets, shadowing standard)
+cindex(widgets, overriding standard)
+User-defined widgets may shadow (override) standard widgets: for instance,
+after `tt(zle -N self-insert myfunc)', any invocation of the standard
+tt(self-insert) widget (including every keypress that appends an alphanumeric
+or space character to the command line) would invoke the user-defined
+function tt(myfunc) rather than the standard implementation of that widget.
+However, each standard widget `var(foo)' is also available under the
+name `tt(.)var(foo)', and this name can't be rebound to a different widget.
+This makes the standard widget available to be called or bound even when
+its usual name has been redefined.
+Therefore, for forward compatibility with future versions of the shell,
+it is recommended that user-defined widgets should not have names
-starting with `tt(.)'.
+starting with `tt(.)'.  (If a user-defined widget is named `tt(.)var(some-name)'
+and a future version of the shell introduces a built-in `var(some-name)' widget,
+the user-defined widget's definition will raise an error under that future
+version of the shell.)
 
+Continuing the example, tt(myfunc) would typically invoke the built-in widget
+it is replacing using the dot-prefix syntax:
+
+example(zle -N self-insert myfunc
+myfunc+LPAR()+RPAR() {
+  [[ $KEYS == [aeiou] ]] && zle .self-insert -- "$@"
+  zle .self-insert -- "$@" 
+})
+
+This example causes vowels to be inserted twice.
+
+Note the use of the dot-prefix syntax.  If the tt(self-insert) widget had been
+invoked without the dot DASH()- that is, as `tt(zle self-insert -- "$@")' DASH()-
+then tt(myfunc) would have been called again, effecting a bottomless
+recursion.
+
 texinode(User-Defined Widgets)(Standard Widgets)(Zle Widgets)(Zsh Line Editor)
 sect(User-Defined Widgets)
 cindex(widgets, user-defined)

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-29 22:55                         ` Daniel Shahaf
@ 2022-05-30  4:04                           ` Bart Schaefer
  2022-05-30  9:07                             ` Peter Stephenson
  2022-06-02  9:59                             ` Daniel Shahaf
  0 siblings, 2 replies; 23+ messages in thread
From: Bart Schaefer @ 2022-05-30  4:04 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh Users

On Sun, May 29, 2022 at 3:55 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Bart Schaefer wrote on Sat, 28 May 2022 18:43 +00:00:
> > On Sat, May 28, 2022 at 3:06 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >> +cindex(widgets, shadowing standard)
> >
> > "Shadow(ing)" is not a term I'd think to search for in this context.
>
>  [...] I think "shadow" is the right term
> here, so how about:
>
> +cindex(widgets, shadowing standard)
> +cindex(widgets, overriding standard)

By comparison to a number of other index entries, I think

standard widgets, shadowing
standard widgets, overriding

Or even

widgets, standard, shadowing
widgets, standard, overriding

would fit the pattern better.

> +User-defined widgets may shadow (override) standard widgets: for instance,
>
> >> +However, each standard widget `var(foo)' is also available under the
> >
> > I would probably have used something like var(std)
>
> Personally I find it easier to read with "foo", but I suppose that's
> a matter of taste.  I'll write it whichever way is the house style.

There are plenty of "foo" already in the doc, so as you prefer.

> >> +Therefore, for forward compatibility with future versions of the shell,
> >> +it is recommended that user-defined widgets should not have names
> >>  starting with `tt(.)'.
> >
> > It's actually prohibited to name a user-defined widget the same as one
> > of the reserved dot-names, so this recommendation could be more
> > specific.
>
> OK, can spell out the problem.  Wouldn't that make the paragraph a bit
> of a wall of text, though?  Also, it would further break the flow

Hm.  How about, picking up after
+This makes the standard widget available to be called or bound even when
+its usual name has been redefined.

These names are reserved and cannot be created as user-defined
widgets, so for compatibility with possible future revisions of the
shell, it is recommended that users avoid naming widgets with a
leading `tt(.)'.


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-28 10:06                     ` Daniel Shahaf
  2022-05-28 18:43                       ` Bart Schaefer
@ 2022-05-30  9:02                       ` Vincent Lefevre
  2022-06-02 10:17                         ` Daniel Shahaf
  1 sibling, 1 reply; 23+ messages in thread
From: Vincent Lefevre @ 2022-05-30  9:02 UTC (permalink / raw)
  To: zsh-users

On 2022-05-28 10:06:39 +0000, Daniel Shahaf wrote:
> Vincent Lefevre wrote on Sat, May 28, 2022 at 02:07:20 +0200:
> > This is in Section "ZLE WIDGETS". But since this is specific to
> > the standard widgets, shouldn't this be also at the beginning of
> > Section "STANDARD WIDGETS"?
> 
> The next paragraph recommends that user-defined widgets not be named
> with leading dots.  That wouldn't belong under "Standard widgets".

Concerning this point, I meant just the end of the paragraph, which
would be *also* in Section "STANDARD WIDGETS". This is because one
does not read the manual in a linear way, and if one is interested
in standard widgets, one may look at this section only.

Or perhaps just the sentence

  Each built-in widget has two names: its normal canonical name, and
  the same name preceded by a `.'.

with a reference to Section "ZLE WIDGETS" for more information.

BTW, are "built-in widget" and "standard widget" synonymous?
The terminology should be clarified and possibly homogenized.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-30  4:04                           ` Bart Schaefer
@ 2022-05-30  9:07                             ` Peter Stephenson
  2022-06-02  9:59                               ` Daniel Shahaf
  2022-06-02 10:19                               ` Daniel Shahaf
  2022-06-02  9:59                             ` Daniel Shahaf
  1 sibling, 2 replies; 23+ messages in thread
From: Peter Stephenson @ 2022-05-30  9:07 UTC (permalink / raw)
  To: Zsh Users

I won't complicate the discussion on the currently proposed text further
(don't see any fundamental problems), but I wonder if it would be useful to
give an example of accept-line being adapted?  There is a problem of making
the documentation too verbose (if technology allowed, it would be useful
to have a two level manual, the fundamentals and a running commentary,
but that's a pipedream), so maybe a self-insert example is good enough.
Alternatively, a subsequent sentence like "In a similar way,
to perform a final action on all lines returned from Zle, the accept-line
widget can be rebound to a function that performs an action on the current
line, then calls the .accept-line widget to return the line to the shell."

pws


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-30  4:04                           ` Bart Schaefer
  2022-05-30  9:07                             ` Peter Stephenson
@ 2022-06-02  9:59                             ` Daniel Shahaf
  1 sibling, 0 replies; 23+ messages in thread
From: Daniel Shahaf @ 2022-06-02  9:59 UTC (permalink / raw)
  To: Zsh Users

Bart Schaefer wrote on Sun, May 29, 2022 at 21:04:54 -0700:
> On Sun, May 29, 2022 at 3:55 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >
> > Bart Schaefer wrote on Sat, 28 May 2022 18:43 +00:00:
> > > On Sat, May 28, 2022 at 3:06 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > >> +cindex(widgets, shadowing standard)
> > >
> > > "Shadow(ing)" is not a term I'd think to search for in this context.
> >
> >  [...] I think "shadow" is the right term
> > here, so how about:
> >
> > +cindex(widgets, shadowing standard)
> > +cindex(widgets, overriding standard)
> 
> By comparison to a number of other index entries, I think
> 
> standard widgets, shadowing
> standard widgets, overriding
> 
> Or even
> 
> widgets, standard, shadowing
> widgets, standard, overriding
> 
> would fit the pattern better.

Let's see:

    % grep -h 'cindex.*widget' *.yo | me
    cindex(completion, widgets)
    cindex(completion widgets, examining and setting state in)
    cindex(completion widgets, adding specified matches)
    cindex(completion widgets, modifying special parameters)
    cindex(completion widgets, condition codes)
    cindex(completion widgets, example)
    .
    cindex(widgets, rebinding)
    cindex(rebinding widgets)
    .
    cindex(widgets, binding)
    cindex(binding widgets)
    .
    cindex(widgets, invoking)
    cindex(invoking widgets)
    .
    cindex(widgets, calling)
    cindex(calling widgets)
    .
    cindex(widgets, defining)
    cindex(defining widgets)
    .
    cindex(completion widgets, creating)
    cindex(widgets)
    cindex(widgets, user-defined)
    cindex(widgets, standard)

Your second option makes sense to me.

I'll also add a pair of "${verb}ing standard widgets" entries for
consistency with the 5 pairs above.

I don't think it's likely people would look for "standard widgets" under 's'…

>

I'll also change the example code so the `zle -N` runs _after_ the
function is defined, to avoid spurious "No such shell function `myfunc'"
warnings if someone copy-pastes the example line by line.

> > +User-defined widgets may shadow (override) standard widgets: for instance,
> >
> > >> +However, each standard widget `var(foo)' is also available under the
> > >
> > > I would probably have used something like var(std)
> >
> > Personally I find it easier to read with "foo", but I suppose that's
> > a matter of taste.  I'll write it whichever way is the house style.
> 
> There are plenty of "foo" already in the doc, so as you prefer.
> 

*nod*

> > >> +Therefore, for forward compatibility with future versions of the shell,
> > >> +it is recommended that user-defined widgets should not have names
> > >>  starting with `tt(.)'.
> > >
> > > It's actually prohibited to name a user-defined widget the same as one
> > > of the reserved dot-names, so this recommendation could be more
> > > specific.
> >
> > OK, can spell out the problem.  Wouldn't that make the paragraph a bit
> > of a wall of text, though?  Also, it would further break the flow
> 
> Hm.  How about, picking up after
> +This makes the standard widget available to be called or bound even when
> +its usual name has been redefined.
> 
> These names are reserved and cannot be created as user-defined
> widgets, so for compatibility with possible future revisions of the
> shell, it is recommended that users avoid naming widgets with a
> leading `tt(.)'.

Thanks.  I'll include this in v3.


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-30  9:07                             ` Peter Stephenson
@ 2022-06-02  9:59                               ` Daniel Shahaf
  2022-06-02 10:19                               ` Daniel Shahaf
  1 sibling, 0 replies; 23+ messages in thread
From: Daniel Shahaf @ 2022-06-02  9:59 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: Zsh Users

Peter Stephenson wrote on Mon, May 30, 2022 at 10:07:25 +0100:
> so maybe a self-insert example is good enough.
> Alternatively, a subsequent sentence like "In a similar way,
> to perform a final action on all lines returned from Zle, the accept-line
> widget can be rebound to a function that performs an action on the current
> line, then calls the .accept-line widget to return the line to the shell."

I'll err on the side of including such an example in v3.

It'll still use the sh function definition syntax; extending
workers/50312 to the docs is beyond the scope of this thread.

> I won't complicate the discussion on the currently proposed text further
> (don't see any fundamental problems), but I wonder if it would be useful to
> give an example of accept-line being adapted?  There is a problem of making
> the documentation too verbose (if technology allowed, it would be useful
> to have a two level manual, the fundamentals and a running commentary,
> but that's a pipedream),

I think it's achievable.  For instance, The TeXbook annotates some
paragraphs as "dangerous bends" (and other paragraphs as "double
dangerous bends") using icons on the the first line of the paragraph.
Those icons designate a paragraph as more advanced material that one may
want to skip on first reading.

For starters, I'll add em(foo) subheadings in v3, as already done in
_arguments.

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-30  9:02                       ` Vincent Lefevre
@ 2022-06-02 10:17                         ` Daniel Shahaf
  2022-06-02 13:54                           ` Vincent Lefevre
  0 siblings, 1 reply; 23+ messages in thread
From: Daniel Shahaf @ 2022-06-02 10:17 UTC (permalink / raw)
  To: zsh-users

Vincent Lefevre wrote on Mon, May 30, 2022 at 11:02:55 +0200:
> On 2022-05-28 10:06:39 +0000, Daniel Shahaf wrote:
> > Vincent Lefevre wrote on Sat, May 28, 2022 at 02:07:20 +0200:
> > > This is in Section "ZLE WIDGETS". But since this is specific to
> > > the standard widgets, shouldn't this be also at the beginning of
> > > Section "STANDARD WIDGETS"?
> > 
> > The next paragraph recommends that user-defined widgets not be named
> > with leading dots.  That wouldn't belong under "Standard widgets".
> 
> Concerning this point, I meant just the end of the paragraph, which
> would be *also* in Section "STANDARD WIDGETS". This is because one
> does not read the manual in a linear way, and if one is interested
> in standard widgets, one may look at this section only.
> 
> Or perhaps just the sentence
> 
>   Each built-in widget has two names: its normal canonical name, and
>   the same name preceded by a `.'.
> 
> with a reference to Section "ZLE WIDGETS" for more information.
> 

Following your argument, why *shouldn't* the information be repeated at
the top of the "User-defined Widgets" section?  It's relevant to users
who define widgets that shadow standard widgets.

Perhaps the right answer here is to demote the "User-defined Widgets"
and "Standard Widgets" sections to subsections of "Widgets", but this
might involve some yodl/texi work to get the _current_ subsections of
these two sections nested one level deeper.  (We reverted this 

> BTW, are "built-in widget" and "standard widget" synonymous?
> The terminology should be clarified and possibly homogenized.

Do we have more than one kind of non-user-defined widget?  If so, those
two terms could be a distinction with a difference [sic].

The difference here could be, say, between widgets that are implemented
by the zsh/zle module and are zmodload'd by default (in the 'zmodload
-F' sense) on the one hand, and other widgets implemented in C.  (I.e.,
widgets implemented by other modules, or by off-by-default 'zmodload -F'
features of the zsh/zle module.)

Or perhaps there isn't any difference.

There's also what the manual terms "Special widgets".

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-05-30  9:07                             ` Peter Stephenson
  2022-06-02  9:59                               ` Daniel Shahaf
@ 2022-06-02 10:19                               ` Daniel Shahaf
  1 sibling, 0 replies; 23+ messages in thread
From: Daniel Shahaf @ 2022-06-02 10:19 UTC (permalink / raw)
  To: zsh-users

v3.  This should incorporate all feedback up to this point.

Cheers,

Daniel

diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo
index 2d033a0a1..7266aa80a 100644
--- a/Doc/Zsh/zle.yo
+++ b/Doc/Zsh/zle.yo
@@ -746,16 +746,67 @@ ifnzman(noderef(Standard Widgets)).
 Other built-in widgets can be defined by other modules (see
 ifzman(zmanref(zshmodules))\
 ifnzman(noderef(Zsh Modules))\
-).  Each built-in widget has two names: its normal canonical name, and the
-same name preceded by a `tt(.)'.  The `tt(.)' name is special: it can't be
-rebound to a different widget.  This makes the widget available even when
-its usual name has been redefined.
+).
 
 User-defined widgets are defined using `tt(zle -N)', and implemented
 as shell functions.  When the widget is executed, the corresponding
 shell function is executed, and can perform editing (or other) actions.
-It is recommended that user-defined widgets should not have names
-starting with `tt(.)'.
+
+cindex(widgets, shadowing standard)
+cindex(widgets, overriding standard)
+cindex(shadowing standard widgets)
+cindex(overriding standard widgets)
+User-defined widgets may shadow (override) standard widgets: for instance,
+after `tt(zle -N self-insert) var(myfunc)', any invocation of the standard
+tt(self-insert) widget (including every keypress that appends an alphanumeric
+or space character to the command line) would invoke the user-defined
+function var(myfunc) rather than the standard implementation of that widget.
+
+In order for the standard implementations to be available to be called by
+user-defined widgets or bound to keypresses even when shadowed, 
+each standard widget `var(foo)' is also available under the
+name `tt(.)var(foo)'.
+These names are reserved and cannot be created as user-defined widgets,
+so for compatibility with possible future revisions of the shell,
+it is recommended that users avoid naming widgets with a leading `tt(.)'.
+
+Continuing the example, var(myfunc) would typically invoke the built-in widget
+it is replacing using the dot-prefix syntax.  For instance:
+
+em(Example #1)
+
+example(self-insert-vowels-twice+LPAR()+RPAR() {
+  [[ $KEYS == [aeiou] ]] && zle .self-insert -- "$@"
+  zle .self-insert -- "$@" 
+}
+zle -N self-insert self-insert-vowels-twice)
+
+This example causes vowels to be inserted twice.  For instance, typing
+`tt(hello)' would insert `tt(heelloo)'.
+
+Note the use of the dot-prefix syntax.  If the tt(self-insert) widget had been
+invoked without the dot DASH()- that is, as `tt(zle self-insert -- "$@")' DASH()-
+then tt(self-insert-vowels-twice) would have been called again, effecting
+a bottomless recursion.
+
+em(Example #2)
+
+In a similar way, to perform a final action on all lines returned from Zle,
+the tt(accept-line) widget can be rebound to a function that performs an action
+on the current line, then calls the tt(.accept-line) widget to return the line
+to the shell.  For example, to change the default behaviour that pressing
+tt(<Enter>) on an empty line redraws the prompt (and runs tt(precmd) hooks,
+if any are configured), one may override accept-line as follows:
+
+example(accept-non-empty-lines+LPAR()+RPAR() {
+    [[ -z $PREBUFFER && -z $BUFFER ]] || zle .accept-line -- "$@"
+}
+zle -N accept-line accept-non-empty-lines)
+
+The special parameters used by these examples DASH()- tt($KEYS),
+tt($PREBUFFER), and tt($BUFFER) DASH()- are documented in the next
+section.
+
 
 texinode(User-Defined Widgets)(Standard Widgets)(Zle Widgets)(Zsh Line Editor)
 sect(User-Defined Widgets)


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: prevent some lines directly coming from the history from being executed
  2022-06-02 10:17                         ` Daniel Shahaf
@ 2022-06-02 13:54                           ` Vincent Lefevre
  0 siblings, 0 replies; 23+ messages in thread
From: Vincent Lefevre @ 2022-06-02 13:54 UTC (permalink / raw)
  To: zsh-users

On 2022-06-02 10:17:00 +0000, Daniel Shahaf wrote:
> Vincent Lefevre wrote on Mon, May 30, 2022 at 11:02:55 +0200:
> > On 2022-05-28 10:06:39 +0000, Daniel Shahaf wrote:
> > > Vincent Lefevre wrote on Sat, May 28, 2022 at 02:07:20 +0200:
> > > > This is in Section "ZLE WIDGETS". But since this is specific to
> > > > the standard widgets, shouldn't this be also at the beginning of
> > > > Section "STANDARD WIDGETS"?
> > > 
> > > The next paragraph recommends that user-defined widgets not be named
> > > with leading dots.  That wouldn't belong under "Standard widgets".
> > 
> > Concerning this point, I meant just the end of the paragraph, which
> > would be *also* in Section "STANDARD WIDGETS". This is because one
> > does not read the manual in a linear way, and if one is interested
> > in standard widgets, one may look at this section only.
> > 
> > Or perhaps just the sentence
> > 
> >   Each built-in widget has two names: its normal canonical name, and
> >   the same name preceded by a `.'.
> > 
> > with a reference to Section "ZLE WIDGETS" for more information.
> > 
> 
> Following your argument, why *shouldn't* the information be repeated at
> the top of the "User-defined Widgets" section?  It's relevant to users
> who define widgets that shadow standard widgets.

I was speaking of Section "STANDARD WIDGETS" because this is precisely
where the names are given, together with the description, e.g.

    accept-line (^J ^M) (^J ^M) (^J ^M)
        Finish editing the buffer.  Normally this causes the buffer
        to be executed as a shell command.

Ideally, one should have all the names:

    accept-line, .accept-line (^J ^M) (^J ^M) (^J ^M)
        Finish editing the buffer.  Normally this causes the buffer
        to be executed as a shell command.

But this would be too much. Hence my suggestion to write something
about that only at the beginning of the section.

Now, Section "USER-DEFINED WIDGETS" should contain examples of
user-defined widgets, in particular using the dot-name form.
So the information would be there too.

> Perhaps the right answer here is to demote the "User-defined Widgets"
> and "Standard Widgets" sections to subsections of "Widgets", but this
> might involve some yodl/texi work to get the _current_ subsections of
> these two sections nested one level deeper.  (We reverted this 

This may not solve the issue, as one may want to immediately jump to
the "Standard Widgets" (sub)section to get information about them.

> > BTW, are "built-in widget" and "standard widget" synonymous?
> > The terminology should be clarified and possibly homogenized.
> 
> Do we have more than one kind of non-user-defined widget?  If so, those
> two terms could be a distinction with a difference [sic].
> 
> The difference here could be, say, between widgets that are implemented
> by the zsh/zle module and are zmodload'd by default (in the 'zmodload
> -F' sense) on the one hand, and other widgets implemented in C.  (I.e.,
> widgets implemented by other modules, or by off-by-default 'zmodload -F'
> features of the zsh/zle module.)

OK, menu-select is a built-in widget defined by zsh/complist, thus
it has a dot-name form, but it is not a standard widget.

zira% zmodload zsh/complist
zira% zle -l | grep menu-select
zira% zle -l -a | grep menu-select
.menu-select
menu-select
zira% 

BTW, for widgets, the manual uses "built-in" and "builtin". I suppose
that this is really the same thing. Also, "user defined widgets"
(several occurrences) should be changed to "user-defined widgets".

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2022-06-02 13:55 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-24 15:47 prevent some lines directly coming from the history from being executed Vincent Lefevre
2022-05-24 18:58 ` Bart Schaefer
2022-05-25  2:54   ` Vincent Lefevre
2022-05-25  3:59     ` Bart Schaefer
2022-05-25  8:49       ` Vincent Lefevre
2022-05-26  1:25         ` Bart Schaefer
2022-05-26 14:36           ` Vincent Lefevre
2022-05-26 15:53             ` Daniel Shahaf
2022-05-26 16:13               ` Peter Stephenson
2022-05-27 12:40                 ` Daniel Shahaf
2022-05-28  0:07                   ` Vincent Lefevre
2022-05-28 10:06                     ` Daniel Shahaf
2022-05-28 18:43                       ` Bart Schaefer
2022-05-29 22:55                         ` Daniel Shahaf
2022-05-30  4:04                           ` Bart Schaefer
2022-05-30  9:07                             ` Peter Stephenson
2022-06-02  9:59                               ` Daniel Shahaf
2022-06-02 10:19                               ` Daniel Shahaf
2022-06-02  9:59                             ` Daniel Shahaf
2022-05-30  9:02                       ` Vincent Lefevre
2022-06-02 10:17                         ` Daniel Shahaf
2022-06-02 13:54                           ` Vincent Lefevre
2022-05-26 16:37             ` 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).