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 df1e1ddd for ; Sat, 13 Jul 2019 12:20:41 +0000 (UTC) Received: (qmail 8365 invoked by alias); 13 Jul 2019 12:20:34 -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: 24056 Received: (qmail 7995 invoked by uid 1010); 13 Jul 2019 12:20:34 -0000 X-Qmail-Scanner-Diagnostics: from mail-vs1-f46.google.com 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(209.85.217.46):SA:0(-2.0/5.0):. Processed in 3.913224 secs); 13 Jul 2019 12:20:34 -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.217.46 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=fs78TaAP7HwaWrUz770bMVA6MAd5WM2J5QgpKoST2As=; b=HoKz8JEdz1fEDcZIy1DPFrAXZRJwkovaZ7HF45KhU6HoyqbHJL9/bSbG55INxNHuGX 18T6+OX+sZzZhFqd9qBMWtWDsihsOSQXKAZ6in33WxO+zLRDerklGJ3r81CSWQtg+0z5 MkOxiS1CsJ35v2nXJ2a7TPoMbxUp8ThBTcLlqmnWqa69+p25b2XFro+ONt+J6ksYs3YO 8KbbWS9nJny0kAj6abnFZRqEY58KA4JzJvd5k0TEJYXtzY1sXL63Vpd5oSJCud2QnaKl C+GNX2hLZT+4//svPwU1BOs0hbbtmJjeeJuRE98aorBdJhM0PWwR1wwN99xNl1VRmHvM 2s8w== 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=fs78TaAP7HwaWrUz770bMVA6MAd5WM2J5QgpKoST2As=; b=kWCiEOR6J3ZHRftnZ+DsidSJF+EjVAtRNpg+MoPvltF+s88RGUjRt1rOoNZv67H7qR 9yTw4d+27rH9SNsMdTwk0tR4ai6f7E8wcIiemkBr5umT2vDmqtXcTjOgc0YRabym/YD5 Z2lkKBf76/rpVO/0FT2Krdi7diYCnEsDs8iocQ9FU4X+f7hvN23aj5gKqyW/jc2hm9XH XjnCEtmZMSRw8JGHax6uxD06zbLzJllaQSgFDPZ/qvFPtGG61KIsC2xxI+TkVf131C1Z k1mZZN+trrH2Vo/FGYssGKHVRlU3Mt5gjZwnVL6LggFR174s7/vwUAzSZjyNA9MWpDWv xdZw== X-Gm-Message-State: APjAAAX/KrzNHda35yG8mThsM6ENUbBu6R3I/p/AMxOCVQdL0FPlMhm6 VCLkdhz77QufZ11uUqyFl11oxf9blrajH2xH4so= X-Google-Smtp-Source: APXvYqwVxmm/ltWcq/ncuLkSXZxmj91olewKxk0yGTpX5DBH1x+gfxd7fzdcAEeJJCVE5NFCwJJbLaGJ86S7TQtch6c= X-Received: by 2002:a67:80c8:: with SMTP id b191mr11838899vsd.113.1563020396129; Sat, 13 Jul 2019 05:19:56 -0700 (PDT) MIME-Version: 1.0 References: <33999-1563008359.364082@ccgB.SxHS.A_VB> In-Reply-To: <33999-1563008359.364082@ccgB.SxHS.A_VB> From: Sebastian Gniazdowski Date: Sat, 13 Jul 2019 14:19:44 +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 Sat, 13 Jul 2019 at 10:59, Oliver Kiddle wrote: > ... The docs also say: "any other zle function not listed leaves menu selection and executes that function." so the widget should be apparently still plainly executed. > ... > } else if (cmd =3D=3D Th(z_acceptandinfernexthistory) { > /* special meaning code for accept-and-infer-next-history */ > ... > } else if .... It seems to me that the main problem / idea is to replace the above check(s) which are keymap-specific to a more general solution, which would: =E2=80=93 allow automatic mapping of an invocation of a widget to a $KEYMAP-variant of the widget =E2=80=93 provide a set of base widgets that are $KEYMAP-specific, so that users can use them as the building blocks of custom widgets. Then: =E2=80=93 the above check(s) are an entry point to a set of such keymap-specific widgets and seem to implement the keymap-specific automatic selection of the widgets, however they're a high level widgets, not a fine-grained building blocks, =E2=80=93 because of this lack of fine-grained widgets the designers of the code decided to not allow overloading of them. Is this correct? Because if yes, then it would seem that the existing mechanism can be still used, if the fine-grained widgets will be provided and the overloading of the widgets will be enabled. > 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: It could be that it's a matter of a hard work of adding the missing, fine-grained widgets like the vi-forward-char in the C code for the menuselect keymap. Or, to provide some even more basic widgets and implement the proper building-blocks (like the vi-forward-char) in Zsh script. > 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. 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? > 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. It sounds versatile but like a hard work. It would create a subsystem with much degrees of freedom. I'm unsure if it would have many use cases. Could you tell some? > 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. Yes, it seems so, it's like implementing a system with many hooks. > PS. bindkey -s will work. Does the following do what you wanted with doub= le-accept? > > bindkey -M menuselect -s ' ' '^@^M' > bindkey -M menuselect '^@' auto-suffix-remove It seems to accept the selection, and the widget is still not called: https://asciinema.org/a/sTCAmyZaJosllGGChZKImtJrt After removing the ^M, it actually does what I need (but with a beep..) =E2=80=93 accepts an entry without appending a space, however not through the widget =E2=80=93 I can put a non-existing widget there and the behavior is the same. -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org