A couple of questions on 'bindkey'

A couple of questions on 'bindkey'

[Anthony Heading]

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?

	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.

	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...)

Regards

Anthony

Re: A couple of questions on 'bindkey'

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

bindkey -A evil ... (was: RE: A couple of questions on 'bindkey' )

[Andrej Borsenkow]

Actually, reading manual one gets impression, that bindkey -A old new is
exactly, what was needed ... after trying

bindkey -A vicmd main (being in emacs by default)

no input was possible. The commands were O.K. (I could get up and down
history, I could even do cw - and word disappeared, as it should), but no
input (self-insert) was possible.

Probably, bindkey should somehow check this condition ...

/andrej

Re: bindkey -A evil ... (was: RE: A couple of questions on 'bindkey' )

[Anthony Heading]

Andrej Borsenkow wrote:
> after trying
> 
> bindkey -A vicmd main (being in emacs by default)
> 
> no input was possible.

Yes.  To be useful 'main' needs I think to be a link to an input type
keymap - either emacs or viins.  But 'evil' is perhaps a little harsh,
no?  What you asked for has clear semantics even if it's not what one
wants.

Anthony

PS.   Having just discovered that in 3.1 things like 'typeset IFS=":"'
seem to be cleverly restored properly at the end of function,  I'm
increasingly thinking that there should after all be a KEYMAP shell
parameter.  

PPS.  For real work - production as they term it - am using 3.0.5-ext-2,
and it's working excellently.  No more random shell crashes.  Thanks
Bart.

Re: A couple of questions on 'bindkey'

[Anthony Heading]

Peter wrote:
> 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.

Mmm hmm. There's sort-of the capacity to do that now by linking to
'main' with the bindkey -A option, but it's somewhat half-arsed. 
Ignoring for a moment if I may what's in place already, I imagined one
putative advantage of a KEYMAP variable is conceptually that it could be
local to a function, and restored implictly on exit using the normal
typeset mechanism.  (Not sure that this works for special variables, but
it might do).  However I'm sure that given the frequent resets to 'main'
of the current keymap that crashing out of a function in a different
keymap might not necessarily be a problem even without 'trap'
shenanigans.

But that's a very helpful answer.  If a shell param doesn't seem
obviously the appropriate way to handle setting such things as keymaps
then it's probably not worthwhile adding the complexity.

> 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.

Well, I meant the whole shebang really.  Case in point - I don't really
understand why you say the output " "-"~" is a big win.  Who wants this
in the first place?  And why are they grateful that it's 94 lines
shorter than it otherwise would be?  For me, it just breaks the ability
to do a simple regexp grep for no real benefit.

Anyhow, I conclude that the existing behaviour is not regarded as
especially egregious.  And as you say, it not exactly rocket science to
maintain.  So I'll try to preserve it.

Thanks

A