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.2 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 0a64b6ad for ; Sun, 14 Jul 2019 10:39:17 +0000 (UTC) Received: (qmail 21530 invoked by alias); 14 Jul 2019 10:39:06 -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: 24060 Received: (qmail 187 invoked by uid 1010); 14 Jul 2019 10:39:06 -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 2.762739 secs); 14 Jul 2019 10:39:06 -0000 X-Envelope-From: SRS0=Gdhn=VL=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=1563100703; bh=PHtrOljqH+gCjeW4LzgqZel47lL4brsGiyUt3TcxJwI=; h=From:References:To:Subject:Date:From:Subject; b=fKot0nFIqQmvUYwqBpjOTnQIa6enSIQlfain3PShJYf0SMByqmu9mGrkmigZxa6Gnp7feK+fHT8RflnZv315hZmYk9o0C8tqAOGaox9v/gUP6VI8Vl8yv0RXoyLkfLHkAruMiGQK/1uTlMp+tuLf5+COZbW9LzZ+4ZNjGc55x0QawJIqv4fb+8qMoC9ZhUOh9wY5QqetkesGt40wsWK3riLnHHAjbRfUns0ltO3QK9dDETJ7nHSSfrdgU7wdRC0coEMwjMG7t6ysnp/FVHe2V7sTcHPxTy6H8AgOanEEGYNNOyBqwLBAnYoC4Lm9E8zP120YkeI0C1QWYM3bfCwhMQ== X-YMail-OSG: ilcDEqIVM1nQV9RxSQgKtsx2.Xjit9sfLR9w4DElaFS0Yyq_Qa8LLwKrnLlY5mo lywPEe0cIcBUo1xCPUaZ4PGRia4jnwsvAbegXuekzYo41hMmUZKSkicvYZIhVkZ6uBXQci1AxtMp _Gu0RPZw1EHO9YlsiYVm8hfmuLBRlGq2Mk4GAvRPwykF1H3fUZjIU3nNUBswOVrFSBHMCc6ebpyb shNi1AyhIri7fP.Tx5tLE0e4QlxvzlhJEVlAuZGB1eFeqG91MlWttRWnl81Bw1_2z.54QDClgBy6 BI2SEmVPjrAz.07WcXeZ2SPauklU1sUl7GE3o9ThLBtc8c.U2sYmiXzjtKDrCRaW5hZCI1myeqr7 8Y7VsV85Q9rCDpDXRhHPqvgS0RctRWI_NW0MdQx0HTfYO0r0DRLgvLs53poZC7Inn4BOu9X_B4L8 TfEgslQEyOalbrWyaSyvUcwc9RXEQBlcZ9jUyx.bPkP4mnk3GsxL8t7DLwOL43vhVMAwrQmu4MSf OXyEiPJMI.sFCVtk8Z5wD_6NjxqU786sSxsoMsUhU_a._oEl.qiJbJa1Z3WuokKtCzTkQ7sVHlLR 9ujy6PVtk2tpC74GauTqMz6.7cD0iq6YuD3L.lkBcJym7zomgn2Zb.K70SE.DSHEUPNjZe0.VKrj RQG_yn5wukN4mZ7lXtKW6D4POgVQqHCNPbKFxtzQnJm6jeIR6qYgz8JkVY_E4aqHeDvYOJERzOOz igGdcaw5wNJSAjWdT0CBL3UUiK0bPkbLqcRtmeZej6adfiEB2z5xfGOagKWx8CoILdI0PUyaeczY BM3DenIqCZsWg5RNOu2KieagaxQLr02KatxEgGtyBjybwGuPD6AeereB1ROTT9J.D_U4ipdihRZR 72GY2IwzK4nKDrigvblSxHq4BAW8lFlo5ouaOK4U0u62Oe6pextp7LUtHgaVvrVGczyzXQlHSX17 SJZ6TedoqgYUeyJYeF26UqCjezzJxTNx1DPM3hE9UWre5Y4w.zmzGgUrAepnR8Xlia_kBQINP841 DGe1LDdEzWFyxq2Jxe0AsWwZSomrdM4iCL5HSC17HQu0rU7xH95XI811WbGIVu1rvnLmYa2RdwD. rJgFc9_QVO3gfVqEyclftONoNMfrR7QrFw5gTjXPgVryzjXJnVvWmd6_rFJXYFJe6l1My31I8U.q 0Ce9cD.H4XgVT_wDHnSAnsoKILcA6lGB3nSyN cc: Zsh Users In-reply-to: From: Oliver Kiddle References: <33999-1563008359.364082@ccgB.SxHS.A_VB> To: Sebastian Gniazdowski Subject: Re: Why the widget bound to menuselect isn't called? MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <53444.1563100701.1@hydra> Content-Transfer-Encoding: 8bit Date: Sun, 14 Jul 2019 12:38:21 +0200 Message-ID: <53445-1563100701.603642@DtMP.e8mM.jHzi> Sebastian Gniazdowski wrote: > 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: > ??? allow automatic mapping of an invocation of a widget to a > $KEYMAP-variant of the widget > ??? provide a set of base widgets that are $KEYMAP-specific, so that > users can use them as the building blocks of custom widgets. Yes. However, there would be further problems like ensuring that non- menu selection widgets abort menu selection and preserve backwards compatibility as far as possible. Providing basic widgets would be the easy (but tedious) part. The automatic mapping is harder because an approach needs to be worked out and designed. > Then: > ??? 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, > ??? 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. 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). > 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. Oliver