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

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> 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.