From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16602 invoked from network); 23 Mar 1999 09:17:22 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 23 Mar 1999 09:17:22 -0000 Received: (qmail 7776 invoked by alias); 23 Mar 1999 09:16:42 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5887 Received: (qmail 7769 invoked from network); 23 Mar 1999 09:16:37 -0000 Message-Id: <9903230900.AA70459@ibmth.df.unipi.it> To: zsh-workers@sunsite.auc.dk Subject: Re: A couple of questions on 'bindkey' In-Reply-To: "Anthony Heading"'s message of "Tue, 23 Mar 1999 04:05:51 NFT." <36F6A29F.A730C19A@magix.com.sg> Date: Tue, 23 Mar 1999 10:00:27 +0100 From: Peter Stephenson Anthony Heading wrote: > Hi, > I'm hacking the keymap code a bit at the moment. Am now looking for a > way to switch between multiple keymaps which is more general than > bindkey -e/-v, and which also allows one to switch keymaps temporarily. > Two possibilities come to mind: > > o Switching via invocation of some new 'keymap' builtin > o setting a magical shell parameter: e.g. KEYMAP=myemacs > > Is either of these a generally preferred mechanism? It's quite possible Zefram intended to add some way of doing this, given the existence of arbitrary keymaps. Probably the most natural way is a new option to bindkey, e.g. `bindkey -S keymap' to select a keymap: select is the word current used in the bindkey entry in the zshmodules manual page, and bindkey already takes a `-M keymap' option to choose which keymap to operate on, so this would fit. > Also, having now ripped 'bindkey' to bits, I have the dull task of > putting it back together. And therein I was somewhat struck by the > heavyweight nature of the code which binds keys to 'ranges'. When this > is really ever needed? Why wouldn't a simple shell loop be a better > solution? Clearly it's needed to support reading back keymaps which > were dumped in this format, but that seems to me somewhat redundant too. I don't quite understand the problem. The C code simply does such a loop in bin_bindkey_bind() in zle_keymap.c, calling bindkey() for each individual key in the range. The only thing I can see to make it cumbersome is the test for the format of the range. I've never used `bindkey -R', but I don't see why it shouldn't be possible to have a looping front-end in C, whatever the underlying code. Or do you mean the listing code for output, bs->firstseq etc.? That's just a convenience to make the output neater. Even there it doesn't need to know how the keys were originally *bound*, just how they happen to be in the current keymap. That's quite useful, since having the output " "-"~" self-insert is a big win compared with the other possibility of showing all 95 characters. > Would it be a good/bad/utterly unacceptable thing to remove this > functionality? (I have to concede a hidden agenda - under my brave new > world the housekeeping to keep track of whether we're in such a range is > even more cumbersome...) Again, the output code is the only time you need to remember where you are. Is it really hard to compare two adjacent bindings in a given keymap you're scanning? -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy