zsh-users
 help / color / mirror / code / Atom feed
From: Vincent Lefevre <vincent@vinc17.net>
To: zsh-users@zsh.org
Subject: Re: prevent some lines directly coming from the history from being executed
Date: Thu, 2 Jun 2022 15:54:20 +0200	[thread overview]
Message-ID: <20220602135420.GB1791337@zira.vinc17.org> (raw)
In-Reply-To: <20220602101700.GD28173@tarpaulin.shahaf.local2>

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)


  reply	other threads:[~2022-06-02 13:55 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-24 15:47 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 [this message]
2022-05-26 16:37             ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220602135420.GB1791337@zira.vinc17.org \
    --to=vincent@vinc17.net \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).