From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,MALFORMED_FREEMAIL, RCVD_IN_DNSWL_NONE autolearn=no autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id e34fd20b for ; Sat, 13 Jul 2019 09:00:19 +0000 (UTC) Received: (qmail 12308 invoked by alias); 13 Jul 2019 09:00:08 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 24054 Received: (qmail 25341 invoked by uid 1010); 13 Jul 2019 09:00:08 -0000 X-Qmail-Scanner-Diagnostics: from park01.gkg.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.2/25503. spamassassin: 3.4.2. Clear:RC:0(205.235.26.22):SA:0(-0.3/5.0):. Processed in 3.106349 secs); 13 Jul 2019 09:00:08 -0000 X-Envelope-From: SRS0=WFBN=VK=yahoo.co.uk=okiddle@bounces.park01.gkg.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at bounces.park01.gkg.net designates 205.235.26.22 as permitted sender) X-Virus-Scanned: by amavisd-new at gkg.net Authentication-Results: amavisd4.gkg.net (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.uk X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1563008364; bh=YwxA3wt6I8lsToLhIasO60R/gC7B+fQK3+Wv8hRM73Y=; h=From:References:To:Subject:Date:From:Subject; b=cfOD2JCsdYxkO8TAEPyJQRO39+VXfGUbecc2a6F2wjlGpwbaK/nqUOqPqi52DKYvmiiwwzW0kqOGgbh4/B6/FWh8hCMYn5zLSDtc+jhs8n3qbJQaI3OWLIaVpliOJe1kPjM+6faEqdX7pxd3JsEjTd2ZZuFiadwUnTJkp6s0GcxUPmYrS2qDZQQr2TLp9BeHcmVoXDDyUgZtbGetaRx/NrPeB4efJTljAMLHBXORaKvwhJMM49IFNgnI3qP3WeWorPOCcxQCK05s7OyByoRSZ2eDHEizvkMgoccpMSLySFM6jEfh+ZzCJcF2nsTI7M7Ga+ITh1ogbSwjNo85wGpDhg== X-YMail-OSG: ciBZ4DYVM1kKQxbJZ9CgwGa3oc5YZDebWNMetMKtGTjL5ZKYr2FlVRbJBD9y.1e Rq5GcmWPK7BpIrz7U2XDV08p8lYZG5P.S6AaRpL2KxRZuyaRntdQPdSka7BUdDwv8TjLluY4WZg8 VdHDe8JrWzVSQaf9eH6HME2OatXwalEY5_ygBa8tL1j7GfI23ZinUCcd1_LBPkUcdMKRwpyOAmCJ DGW_eG_Cw7FiGUa0W7VWThEB3uRTIheEAb.9o_RLRPpsCW.6WaWLVcpOeEgISdaxdGiB_paBsgIQ p0RPZA20O5RNgHN_57i0xpFNNYmoMUWHFRVgSpg4CcqNJUCW9q35Y1loWEYsHz1i2ecwfp7xGei1 VqzfZqCYob0cJ1ObS0D8lN64_yu0xwfX8069j6efZyZwgWEtT8ugHKNFds7nd5SNNyPY.x34Pr7g CVfr5RAA9Jyv6BLXFmX.XIW4amM6KdJtj2sE4WqgEjnLORptZVFOoDOI5CB8Ab57qb2dsdVmEQ1f hEwqWAjlTsSvEWPwSu.zjlpfi.fff6NlYwNyya3mZS6civHTVfh6xS7fNC3ZXm8lwyhZ0j_t3VAb 0IdS8HeY84sAJcE_T9ITqHTnBRQAUxsBG3jKprT1MX622lVHzY0cs72p9hhGl7H9r_MSnOE_MjpI lavia9R13zj1kjTnLWHB5BaU.SgUNEStbrAKlj5.FawTHAwf29cBeukPPb6tXSh2EpLQxakI2kRr VxDaodJmldoPuGRI5tAlhb._4QTpwFHgecdLRpLTbS6d2oOwOPFmAmCYxi4BvPAUsm4V2aI8Oz.X 0GnBwxpJ5F8O4QCVOn56tCFxoJB.h890Moy9MGJW0yxbH2SNFoG6CqnII7q5XEZlEMfxKtrZJVsi GgT2QbfIjUnMvbCrIZjLXEZV6vTR7qbYd2vwbO9AzVB_cxCQr6SlT.K.N_qbxZn7ZTLs3dxb5cId aZ_T1GlA7Q7b5Dw0QdHrl0VckokRcWOwdlEOK1VP3M4F2Tmz.VieghP.N.IRhoOpuhaloXFMByFE lPnwL7mt73GRzY3mXy_nycsff51KfMhwsQ.rfiRXNy__M9i0TaZLlWaVuHkZbHQKqrKHlSAsc4d5 UzIbH8fD4qtz_wk2wwbPt6h6OzUGZO.8SPNd7c4z8BRGhrdZo5jQOof.lck3eV8KBknkd6aKgJ4x wVkqvCzC8RjXBfWljEWBbMFggcb45 cc: Zsh Users In-reply-to: From: Oliver Kiddle References: To: Sebastian Gniazdowski Subject: Re: Why the widget bound to menuselect isn't called? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <33998.1563008359.1@hydra> Date: Sat, 13 Jul 2019 10:59:19 +0200 Message-ID: <33999-1563008359.364082@ccgB.SxHS.A_VB> Sebastian Gniazdowski wrote: > function double-accept { echo 1 >> /tmp/reply; } > zle -N double-accept > bindkey -M menuselect ' ' double-accept > > Why? Because custom widgets aren't supported by complist and never have been. In the documentation for the complist module, just before the effect of the various zle widgets are described, it states: The following zle functions have special meaning during menu selection. Note that the following always perform the same task within the menu selection map and cannot be replaced by user defined widgets, nor can the set of functions be extended: That doesn't really answer your question of "Why?" but this isn't easy to explain briefly. What follows is more suited to -workers: It is a feature to give "special meaning" to existing widgets for something like menu selection. Consider something like accept-and-infer-next-history: accepting the current selection and allowing menu selection to continue is conceptually very similar to accepting a line from history and moving to the next one. So the special meaning allows whatever key a user configured to accept-and-infer-next-history to do something similar in menu selection. Note that the menuselect keymap is a local keymap so only acts to override bindings in whatever your main keymap is. complist is implemented as a module so the code for accept-and-infer-next-history can't check whether menu selection is active unlike the checks for, e.g. the region being active. So the complist code does stuff like: cmd = getkeycmd(); ... if (cmd == TH(z_viinsert)) { /* enter interactive mode */ ... } else if (cmd == Th(z_acceptandinfernexthistory) { /* special meaning code for accept-and-infer-next-history */ ... } else if .... ... } else /* any other widget */ ungetkeycmd(); /* accept selected match */ If you search for getkeycmd() in zle_main.c, you'll see it followed by a call to execzlefunc(). It isn't just menuselect but also the command, isearch, listscroll keymaps where this happens. When incremental history was implemented, we didn't have local keymaps or user defined widgets so the implementation there was perfectly natural at the time. If you're wondering what it would take to make this work while not breaking exist user's keybindings, the short answer is quite a lot. Primarily, we need to handle keymap specific special meanings some other way: We could take the concepts embodied in Functions/Zle/keymap+widget and enshrine it in the C code. I'm not sure I entirely like that because you end up with menuselect+forward-char and menuselect+vi-forward-char widgets rather than a single menuselect-next-match. And how do you reassign forward-char to be column-right rather than next-match (we've had user questions in the past about right-cursor moving to the next row from the last column). A user might just rebind l or cursor-right or whatever but a plugin may want to act independently of the actual keys. Perhaps menuselect+forward-char etc could be aliases. We could allow zle widget aliases to be keymap specific. So we'd predefine the aliases and they could be changed, e.g: zle -A forward-char -M menuselect menuselect-column-right A more flexible approach might be to allow conditional zle widget aliases. The condition could be zstyle-like encompassing things like whether the region is active, keymap, PS2 active, completion active, lastwidget. Does that sound useful or over-complicated? keymap+widget might be a useful just as a naming convention. Once before when this was vaguely discussed, Bart mentioned emacs minor modes. Does anyone know how those are implemented underneath? Aside from that new mechanism, there'd be lots of factoring out of special widgets into their own functions and making sure they don't crash the shell if invoked in the wrong context. It'd inevitably also lead to some extra APIs to allow finer control of menu selection such as the example I gave about moving right when already on the last column. Oliver PS. bindkey -s will work. Does the following do what you wanted with double-accept? bindkey -M menuselect -s ' ' '^@^M' bindkey -M menuselect '^@' auto-suffix-remove