Re: prevent some lines directly coming from the history from being executed

[Vincent Lefevre <vincent@xxxxxxxxxx>]

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@xxxxxxxxxx> - 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)