zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <pws@ibmth.df.unipi.it>
To: zsh-workers@sunsite.auc.dk
Subject: Re: A couple of questions on 'bindkey'
Date: Tue, 23 Mar 1999 10:00:27 +0100	[thread overview]
Message-ID: <9903230900.AA70459@ibmth.df.unipi.it> (raw)
In-Reply-To: "Anthony Heading"'s message of "Tue, 23 Mar 1999 04:05:51 NFT." <36F6A29F.A730C19A@magix.com.sg>

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 <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy


  reply	other threads:[~1999-03-23  9:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-03-22 20:05 Anthony Heading
1999-03-23  9:00 ` Peter Stephenson [this message]
1999-03-23 12:41   ` bindkey -A evil ... (was: RE: A couple of questions on 'bindkey' ) Andrej Borsenkow
1999-03-24  4:07     ` Anthony Heading
1999-03-23 17:39 A couple of questions on 'bindkey' Anthony Heading

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9903230900.AA70459@ibmth.df.unipi.it \
    --to=pws@ibmth.df.unipi.it \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).