Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: add-zle-hook-widget and multiple hooks
- X-seq: zsh-workers 46027
- From: Mikael Magnusson <mikachu@xxxxxxxxx>
- To: Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>
- Subject: Re: add-zle-hook-widget and multiple hooks
- Date: Mon, 8 Jun 2020 19:52:00 +0200
- Cc: zsh-workers@xxxxxxx
- In-reply-to: <20200608061425.034f9d90@tarpaulin.shahaf.local2>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <20200606084054.GA31628@tarpaulin.shahaf.local2> <CAHYJk3Rtfj=cfhRpnBhzBUjbF2_9R5W9vG4a68qT84pH9xVRGA@mail.gmail.com> <20200608061425.034f9d90@tarpaulin.shahaf.local2>
On 6/8/20, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> [moving Eric to bcc]
>
> Mikael Magnusson wrote on Sat, 06 Jun 2020 13:58 +0200:
>> On 6/6/20, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
>> > When two or more zle-line-pre-redraw hooks are registered using
>> > add-zle-hook-widget, the value of $LASTWIDGET when the each hook is
>> > called is the name of the former hook:
>> >
>> > [Eric Freese wrote in
>> > https://github.com/zsh-users/zsh-autosuggestions/issues/529#issuecomment-632113840]
>> > $ zsh -df
>> > % autoload add-zle-hook-widget
>> > % f() {}
>> > % g() { zle -M "$(typeset -p LASTWIDGET)" }
>> > % add-zle-hook-widget line-pre-redraw f
>> > % add-zle-hook-widget line-pre-redraw g
>> > % x<CURSOR>
>> > typeset -r LASTWIDGET=f
>> >
>> > The issue here is that g would like to to know what widget was invoked
>> > immediately before the redraw. In the example, that'd be self-insert.
>> >
>> > I've attached two proofs of concept. WDYT?
>> >
>> > I'll add docs, etc, once an approach is chosen.
>> >
>> > Cheers,
>> >
>> > Daniel
>> >
>> > P.S. For the latter patch, note that «zle $widget -f» is distinct from
>> > «zle -f».
>>
>> I think the warning message when -f is not followed by nolast should
>> be phrased in the same way it would if there were other valid flags,
>> since it would have to change when more are added anyway (we will
>> probably not want to enumerate all possible flags in this warning
>> message).
>
> Thanks for the review.
>
> If we add more flags that are too many to list, then we should change
> the error message, yes; nevertheless, _right now_ only one flag is
> supported, so the error message might as well say that. That'd be
> a feature, not a bug. Compare:
>
> % ssh $foo svn info --show-item=dept
> svn: E205000: 'dept' is not a valid value for --show-item; did you mean
> 'depth'?
> % ssh $bar svn info --show-item=dept
> svn: E205000: 'dept' is not a valid value for --show-item
>
> When I'm on $bar and get that error message, I know not to bother
> trying the correct spelling because it won't work. Same here: If 5.9
> supports -f nolast, 5.10 supports -f somethingelse as well, and then
> somebody tries -f somethingelse in 5.9, a generic error message will
> be less helpful to them than a specific one.
>
>> Also, I think rather than reusing the concept of the -f option, it
>> would be better to use another flag (maybe -l for LASTWIDGET) which is
>> analogous to the existing -w option:
>
> _Why_ would that be better?
(sorry if the following is a bit rambly)
Just seems more consistent to me to have -l and -w, rather than -w and
-f nolast/unrelated/flags. The point of the generic -f is that there
had to be some option to initiate that mode of modifying global(ish)
state without actually calling a widget, and adding 4 options instead
of just one option that did 4 very related things felt weird. In a
sense -f is like -N there, it is its own mode of operation. Eg, you
can say zle -f yank kill and both words are arguments for -f (in a
sense).
In this case you're only adding a single flag and that flag is related
to an existing option, and it is (for now) just a very long way to
spell -l. It doesn't start a separate mode of operation, just modifies
the current operation slightly. It's not like we're short on letters
for options in the zle widgetname -opt namespace either (only 4 are
used, 2 of which are already capital letters). I think if we added
more flags to your -f scheme, the convention would by necessity be -f
nolast -f unrelated, which is inconsistent with the zle -f flag.
--
Mikael Magnusson
Messages sorted by:
Reverse Date,
Date,
Thread,
Author