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=DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20342 invoked from network); 8 Jun 2020 17:52:48 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 8 Jun 2020 17:52:48 -0000 Received: (qmail 8891 invoked by alias); 8 Jun 2020 17:52:35 -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: 46027 Received: (qmail 19913 invoked by uid 1010); 8 Jun 2020 17:52:35 -0000 X-Qmail-Scanner-Diagnostics: from mail-il1-f193.google.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(209.85.166.193):SA:0(-2.0/5.0):. Processed in 1.165123 secs); 08 Jun 2020 17:52:35 -0000 X-Envelope-From: mikachu@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.166.193 as permitted sender) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=WKWZziVW+asdmrWE863scjH/gG3N2snKCeVn9X1tSTM=; b=YEkTQX5TZCBaawE2RaiVvY5KjZm2CxN9bpBWU5x5wDdWLfRDHhf/n9jqivSABPq2YM sHxWlD8rJjyzHlZ0zwJn7e3imfJwn9ECXmhkf2XRF4prp4zEPx3TDANQeqbfwECFkJz2 sWGrREhUgRz3GGNou80iObBk7reOqRKXEVqlRT/2KIWoc6GqWyHlKmkpctemSf6mg4Et tKDaJ/uQYylmDAtakUWBx1LAgLRYOA36H+qzu9to0pay+pVkuSKLklOO1UUKqYXZuHG3 UgjUl2W9dTZqEtI+8oqsxkKs9ELGxUKXo1LN6KKyVnHK0C5dFGiyGcisgqx5LKg+4CC9 5COw== X-Gm-Message-State: AOAM533dThYxEjihiBk+5prslr0aWCJiAYgiJ0hzXXR3Q+9HBeZW1vWh NlVOtjZOQnbdIvBvVMplq9IAhdXO9Tt5Hhi/Dd5F+g== X-Google-Smtp-Source: ABdhPJyNGTID44aPDAR5p+2lg2ORoPPKh0tzuyYx77rKBo/CVsdj/Dy8XhpUBzRmz26EQgFnoYcZ58WSPmIfbxWVvGg= X-Received: by 2002:a05:6e02:1212:: with SMTP id a18mr21269067ilq.159.1591638721182; Mon, 08 Jun 2020 10:52:01 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20200608061425.034f9d90@tarpaulin.shahaf.local2> References: <20200606084054.GA31628@tarpaulin.shahaf.local2> <20200608061425.034f9d90@tarpaulin.shahaf.local2> From: Mikael Magnusson Date: Mon, 8 Jun 2020 19:52:00 +0200 Message-ID: Subject: Re: add-zle-hook-widget and multiple hooks To: Daniel Shahaf Cc: zsh-workers@zsh.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 6/8/20, Daniel Shahaf wrote: > [moving Eric to bcc] > > Mikael Magnusson wrote on Sat, 06 Jun 2020 13:58 +0200: >> On 6/6/20, Daniel Shahaf 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#issuecomme= nt-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 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 =C2=ABzle $widget -f=C2=BB is di= stinct from >> > =C2=ABzle -f=C2=BB. >> >> 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=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. > >> 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. --=20 Mikael Magnusson