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 08c2bcb7 for ; Sat, 13 Jul 2019 12:23:57 +0000 (UTC) Received: (qmail 19735 invoked by alias); 13 Jul 2019 12:23:50 -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: 24057 Received: (qmail 17143 invoked by uid 1010); 13 Jul 2019 12:23:50 -0000 X-Qmail-Scanner-Diagnostics: from mail-vs1-f47.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.47):SA:0(-2.0/5.0):. Processed in 3.057737 secs); 13 Jul 2019 12:23:50 -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.47 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=Y07ztp2CuTdT0qBxH+oLhvHzsUhT6tf6xW8lc4yl8JE=; b=dcQb6jIuiOz/hGDFEkv5USQsARDwEFd+t37BcbbmVX6nr0QNuS9C75SiAGvSIZVcvD l6jHdp1O0CHTp88O1YmWb8my7B/iq8Kk/sICIAtelmpGiba1hy0tMb/PgzkNi04Ip1Q9 xDmqiCHlqpm/mji0o9iUugkXchZiYhzQTlngo8e6RCY+KH5bOX1w4HYYhN0GXCqPHoqf v/RzDpY957umi2375PNXXnj5o6yzjS0amEqQ0HqOk53W1CYl/HoBYd5L9swd6Ct/quSA phkbqbnA6YtgM0dVJG2GzTuq3a0CEhM7AkqNRncUNKxk5116c/DGTjdDUawkMwxYpw7u 8dKQ== 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=Y07ztp2CuTdT0qBxH+oLhvHzsUhT6tf6xW8lc4yl8JE=; b=OBIsIm3sbYw98kAvDKvx7MP7j5pzcBAhWP0kvORkTuDP8IZkEjxJZrUuZrikcIYD3t MwQzr7f9YJMaPr8oJi49TkkQEz01OI3nzd8NRC3qfRvFsV2E6pIB0feJvGDEvqMOYS/X U7hB/01lJj8wqcsV5iTIRzagV3WS0aVFaIQu0GZ7hzaoLKmDtC791eUOyaT9z5LxEku4 7Pqd0FefMSl/kvVt0eBgSD95HtBCglefUTsgZSZMJpXbKYO9ZDu1moZQf8kE0h5UzKy8 d2aC/VfXDzgPNvmRIIoFgyKsgFWnEq0m9TKMLNM19Q+emr+F3GzBQPlyRe2UNqad8sd1 uhSg== X-Gm-Message-State: APjAAAVOrzAYfvCleNpKtwTGbji7NpbU2rmzsWXdSWalIvel2whQGTom dl6ScxCgXdY9ASCwo+uTiKND/klw7CSfGdewRrk= X-Google-Smtp-Source: APXvYqxLVZ/tMoBhSMzYC5b5lXlw3ze7tecnWTSdnNjq33bRX+Dm2DUjq91L6/ugkBBHEkg8+gwpfp2FvqlCmtu1zKY= X-Received: by 2002:a67:8e0a:: with SMTP id q10mr11156618vsd.215.1563020594731; Sat, 13 Jul 2019 05:23:14 -0700 (PDT) MIME-Version: 1.0 References: <33999-1563008359.364082@ccgB.SxHS.A_VB> In-Reply-To: From: Sebastian Gniazdowski Date: Sat, 13 Jul 2019 14:23:03 +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 > 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 I meant: only for the menuselect keymap / complist module, to solve that particular problem. On Sat, 13 Jul 2019 at 14:19, Sebastian Gniazdowski wrote: > > 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 tha= t > 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 t= he > 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 othe= r > > 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 ro= w > > 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 a= s > > 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 do= uble-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 th= e > 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 --=20 Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org