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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham 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 1375ede9 for ; Sun, 14 Jul 2019 21:57:00 +0000 (UTC) Received: (qmail 26336 invoked by alias); 14 Jul 2019 21:56:49 -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: 24061 Received: (qmail 3855 invoked by uid 1010); 14 Jul 2019 21:56:49 -0000 X-Qmail-Scanner-Diagnostics: from mail-ua1-f50.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.2/25510. spamassassin: 3.4.2. Clear:RC:0(209.85.222.50):SA:0(-2.0/5.0):. Processed in 2.550117 secs); 14 Jul 2019 21:56:49 -0000 X-Envelope-From: sgniazdowski@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.222.50 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bmlfLmpjiDqxA+TB5PHPfgkzGiGQHK8nm4QPY28kJ1E=; b=VPTOHI7+CYLjqxC5qYSeU9CxVK0lCyHpkp0XII/8YiFFmpLgeDyHlB+FpOLpvbSjWl cvjOO9hYjODkBqbTlgCzCTxVBqQ1BJMcUoYb3vUSb2V9aVLIxqT1NtDisixJ8RTNkDh0 6Dz7BHsFCSh7ir+5ssldJ3/7a/wYPNUt9/HUTQ9KPdy+xmQ539GMZNxCDR4jJb4Jm9dT ii9SvWxr5R9Fc5lBfWzdnbFbJt3E3OMRZNjDqz+/eAIsIT07LjkY+Jhw5CmI7j/Gd/74 ouMgf3zoYkPee32h8/LopocS1bQw9GUxQMER7oZ7aepKScBP4OSqNFDhAv8WxPe2YJ12 f9Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bmlfLmpjiDqxA+TB5PHPfgkzGiGQHK8nm4QPY28kJ1E=; b=NgCR88+LpPuxinCwA1LqKnRAjAQiDz0tgy7l31W0lNxZDmaFNe3BdheiQtZkNs83qu H7KRyHxt/67zY2xDGNjrhLNVVbU/0OXmOMxHVWCJAsKZnD5uijfxpIJ0/IJAfZ2Clc3a r6ptwtYTs4+lkwnmpDMuMIGSWq5AflWxGSapp33B7Gf4Krv1N1vGyKWOx7cBAa0QGnUd g7e36w4SvFIfb18B7Rb5MptYDvIfXtihrJwhRWB7RAFjSaOFbnG3reWQ5v5YEpSPR1lP Y+IKHO/ocF3T3Rki97lUEdpl78MEL3r4u87NV3sxYbhAtZWM4+S1UJuV/LjPhcz4oqtP LiyA== X-Gm-Message-State: APjAAAUo78NuRlR7kgtrXlGL7doGUX5ViuiIeYQ89Vxe65f0EO6QKLU/ 8QD651JJSbNluBTT5zzzjNgl0IYzJXIVrqy+BWI= X-Google-Smtp-Source: APXvYqyoOedb+9rcB3Wa8a5qsa9PtHRcxsBVZxdaQgC+KQLfAJPfUY8Rx+tUJPiSkmSdz3Pv9wCHEayca7qdl8e5pIE= X-Received: by 2002:ab0:2650:: with SMTP id q16mr14541320uao.7.1563141373000; Sun, 14 Jul 2019 14:56:13 -0700 (PDT) MIME-Version: 1.0 References: <33999-1563008359.364082@ccgB.SxHS.A_VB> <53445-1563100701.603642@DtMP.e8mM.jHzi> In-Reply-To: <53445-1563100701.603642@DtMP.e8mM.jHzi> From: Sebastian Gniazdowski Date: Sun, 14 Jul 2019 23:56:01 +0200 Message-ID: Subject: Re: Why the widget bound to menuselect isn't called? To: Oliver Kiddle Cc: Zsh Users Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 14 Jul 2019 at 12:38, Oliver Kiddle wrote: > The automatic mapping is harder > because an approach needs to be worked out and designed. > ... > I'm not sure I follow what you're saying. It may have been better if > there had been fine-grained widgets to begin with but that alone is not > sufficient (either now or at the time of the module's inception). I was making a point that the automatic mapping solely for the menuselect case is actually available =E2=80=93 despite being probably not = at the level of quality and design that we would expect from it =E2=80=93 beca= use the complist module does automatically get the calls if they're done on the menuselect keymap. So to solve the particular issue with non-overloadable menuselect widgets what has to be done is to provide the rest of the Zle widgets =E2=80=93 to give them meaning in the menuselec= t keymap, so that there's no risk that user's overloading widget will call something's unimplemented =E2=80=93 the Zsh script code isn't a threat here, only the dot- i.e. original zle .widgets are. > > It seems that it is about forwarding the keymap-specific mechanism to > > the Zshell code in an consistent way with the C code. The question is > > is this necessary? > > Consistency with Functions/Zle/keymap+widget isn't necessary. > Not breaking backwards compatibility that allows menu selection key > bindings to reflect users' normal key bindings is necessary. I was > trying to outline some vague ideas on how this might be approached. I wonder if the enabling of overloading of the menuselect keymap doesn't break the backwards compatibility. The "always leave menu-selection" behavior, for example, will be changed by it. An configuration option, rather preferably zstyle, could be used to guard the compatible behavior (BTW. are zstyles used to influence Zshell at the C level currently?). --=20 Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org