From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3559 invoked from network); 10 Jun 2020 13:35:46 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 10 Jun 2020 13:35:46 -0000 Received: (qmail 16458 invoked by alias); 10 Jun 2020 13:35:38 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 46039 Received: (qmail 15817 invoked by uid 1010); 10 Jun 2020 13:35:38 -0000 X-Qmail-Scanner-Diagnostics: from wout1-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25835. spamassassin: 3.4.4. Clear:RC:0(64.147.123.24):SA:0(-2.6/5.0):. Processed in 4.851038 secs); 10 Jun 2020 13:35:38 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehiedgieelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkjghfofggtgfgsehtqh dttdertdejnecuhfhrohhmpeffrghnihgvlhcuufhhrghhrghfuceougdrshesuggrnhhi vghlrdhshhgrhhgrfhdrnhgrmhgvqeenucggtffrrghtthgvrhhnpeelvdevvddvledthf elhefgtdduteejueejleeulefgvdehheehheegveelgeelvdenucffohhmrghinhepghhi thhhuhgsrdgtohhmnecukfhppeejledrudejiedrfeelrdeileenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegurdhssegurghnihgvlhdrshhh rghhrghfrdhnrghmvg X-ME-Proxy: Date: Wed, 10 Jun 2020 13:34:52 +0000 From: Daniel Shahaf To: Mikael Magnusson Cc: zsh-workers@zsh.org Subject: Re: add-zle-hook-widget and multiple hooks Message-ID: <20200610133452.025cfc54@tarpaulin.shahaf.local2> In-Reply-To: References: <20200606084054.GA31628@tarpaulin.shahaf.local2> <20200608061425.034f9d90@tarpaulin.shahaf.local2> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mikael Magnusson wrote on Mon, 08 Jun 2020 19:52 +0200: > On 6/8/20, Daniel Shahaf wrote: > > [moving Eric to bcc] > > > > Mikael Magnusson wrote on Sat, 06 Jun 2020 13:58 +0200: =20 > >> On 6/6/20, Daniel Shahaf wrote: =20 > >> > 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#issuecom= ment-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 > >> > typeset -r LASTWIDGET=3Df > >> > > >> > The issue here is that g would like to to know what widget was invok= ed > >> > immediately before the redraw. In the example, that'd be self-inser= t. > >> > > >> > 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 =C2=ABzle $widget -f=C2=BB is = distinct from > >> > =C2=ABzle -f=C2=BB. =20 > >> > >> 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). =20 > > > > 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=3Ddept > > svn: E205000: 'dept' is not a valid value for --show-item; did you mean > > 'depth'? > > % ssh $bar svn info --show-item=3Ddept > > 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. > > =20 > >> 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: =20 > > > > _Why_ would that be better? =20 >=20 > (sorry if the following is a bit rambly) >=20 > Just seems more consistent to me to have -l and -w, rather than -w and > -f nolast/unrelated/flags. I can't parse the last word. In any case, one of the reason I used the same option letter is that both -f flags set bits of the same bitfield type. Even if right now there's no bit that both -f flags set, I suspect one might be added in the future. (For example, a use-case for =C2=ABzle -f nolast=C2=BB doesn't seem inconceivable, even if I don't have = one on me.) > 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). Yes, =C2=ABzle -f=C2=BB is a subcommand (like =C2=ABgit foo=C2=BB). All zl= e subcommands are named as option flags, except for the "invoke a widget" subcommand which is anonymous. > 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. That's what option flags usually do. For example, that's what the -l flag to ls(1) does. > 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). The difference will come once we support both =C2=AB-f nolast=C2=BB and =C2= =AB-f foo=C2=BB. Then each such foo we add will save an option letter, and the API will be easier to remember due to using more meaningful names. > 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. They could also be =C2=AB-f nolast:unrelated=C2=BB, just like the $PATH env= var in relation to the $path array. We could even teach the toplevel -f to support this syntax alongside the existing one for consistency, or teach it to ignore flags called "-f" in its positional arguments, or add a =C2=AB= -f foo=C2=BB value that's an alias of -w, etc.. Over here the jury's still out. Cheers, Daniel