zsh 4.3.4: bindkey -s xx 'yyy\n' no longer works (with bindkey -v)

zsh 4.3.4: bindkey -s xx 'yyy\n' no longer works (with bindkey -v)

[Jim Meyering]

Hello,
First, thanks for maintaining zsh!

I've used the following for ages:

    # Make ^X^X do !!\n
    # This is more direct, but not as nice: bindkey -s '^x^x' '!!\n'
    bangbang () {
      zle .up-history
      zle .accept-line
    }
    zle -N repeat-last-command bangbang
    bindkey '^x^x' repeat-last-command

With 4.2.5, it stopped working.
A little experimenting suggests that no multi-character
LHS sequence works.

With e.g., 4.2.5, the following worked fine:

  g$ zsh -f
  g% bindkey -v
  g% bindkey -s '^x^x' '!!\n'
  g% echo foo
  foo
  g% !!                  <<=== here I typed control-X twice, and no newline
  echo foo               <<=== and it does what I expect
  foo
  g% 

But with 4.3.4, the latter bindkey seems to have no effect:

  r$ zsh -f
  r% bindkey -v
  r% bindkey -s '^x^x' '!!\n'
  r% echo foo
  foo
  r% ^X^X                <<=== here I typed control-X twice,
                               and it merely echos them

I searched the FAQ, release notes, etc. but didn't see any reference to a
deliberate change in behavior.

Re: zsh 4.3.4: bindkey -s xx 'yyy\n' no longer works (with bindkey -v)

[Peter Stephenson]

Jim Meyering wrote:
> But with 4.3.4, the latter bindkey seems to have no effect:
> 
>   r$ zsh -f
>   r% bindkey -v
>   r% bindkey -s '^x^x' '!!\n'
>   r% echo foo
>   foo
>   r% ^X^X                <<=== here I typed control-X twice,
>                                and it merely echos them

The only feature I can see that would have an effect on this is
$KEYTIMEOUT.  This is the delay in 100ths of a second for which the chip
will wait for an additional key if the key typed so far is also bound in
its own right.  However, the default (40) hasn't changed.  What does
"echo $KEYTIMEOUT" say?  Do this behaviour change if you set KEYTIMEOUT
to something larger?

Although, again, I'm not aware of the behaviour deliberately being
changed, the reason $KEYTIMEOUT is applied is because most characters,
including ^X, are bound by default to self-insert in vi insert mode.
You can stop this happening for ^X:

bindkey -r -M viins '^x'

Now it doesn't matter what delay there is between the two ^x's.

Possibly displaying the binding of ^x with

bindkey -M viins '^x'

will shed some light on differences between versions.

(I don't think you need the "-M viins" in either case, but I'm paranoid
about vi keymaps since I can never remember which is the "alternate"
keymap.)

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview

Re: zsh 4.3.4: bindkey -s xx 'yyy\n' no longer works (with bindkey -v)

[Jim Meyering]

Peter Stephenson <pws <at> csr.com> writes:
>  What does
> "echo $KEYTIMEOUT" say?  Do this behaviour change if you set KEYTIMEOUT
> to something larger?

It's 40 for me, too.
Tried bigger, but no change.

> Although, again, I'm not aware of the behaviour deliberately being
> changed, the reason $KEYTIMEOUT is applied is because most characters,
> including ^X, are bound by default to self-insert in vi insert mode.
> You can stop this happening for ^X:
> 
> bindkey -r -M viins '^x'

Bingo!
Once I've done that, ^X^X once again does what I've come to expect.

> Now it doesn't matter what delay there is between the two ^x's.
> 
> Possibly displaying the binding of ^x with
> 
> bindkey -M viins '^x'

Before I did the "-r", it produced this:
  "^X" self-insert

Thanks!

Re: zsh 4.3.4: bindkey -s xx 'yyy\n' no longer works (with bindkey -v)

[Bart Schaefer]

On Apr 24,  1:31pm, Jim Meyering wrote:
}
} But with 4.3.4, the latter bindkey seems to have no effect:
} 
}   r$ zsh -f
}   r% bindkey -v
}   r% bindkey -s '^x^x' '!!\n'
}   r% echo foo
}   foo
}   r% ^X^X                <<=== here I typed control-X twice,
}                                and it merely echos them

I am not able to reproduce this.  You'll have to provide some more
information about your OS, how zsh was compiled, etc.

Re: zsh 4.3.4: bindkey -s xx 'yyy\n' no longer works (with bindkey -v)

[Jim Meyering]

Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Apr 24,  1:31pm, Jim Meyering wrote:
> } But with 4.3.4, the latter bindkey seems to have no effect:
> }
> }   r$ zsh -f
> }   r% bindkey -v
> }   r% bindkey -s '^x^x' '!!\n'
> }   r% echo foo
> }   foo
> }   r% ^X^X                <<=== here I typed control-X twice,
> }                                and it merely echos them
>
> I am not able to reproduce this.  You'll have to provide some more
> information about your OS, how zsh was compiled, etc.

I first saw this problem with Debian unstable's zsh-4.3.4-2 on
x86_64-linux-gnu (amd64).  kernel: 2.6.18-4-amd64, and libc6 2.5-3.
I also built from the latest cvs sources, in that same environment,
including e.g., gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21).

I configured/built/installed like this:
  ./configure --prefix=/t/zz --disable-dynamic && make && make install
then ran /t/zz/bin/zsh -f.

[BTW, without --disable-dynamic, not much worked, since it couldn't
find any modules, e.g., zle]

FWIW, $KEYTIMEOUT was 40, and I tried setting it (via "export KEYTIMEOUT=N")
with values of 100 and 100000, with the same result.

Re: zsh 4.3.4: bindkey -s xx 'yyy\n' no longer works (with bindkey -v)

[Peter Stephenson]

Jim Meyering wrote:
> [BTW, without --disable-dynamic, not much worked, since it couldn't
> find any modules, e.g., zle]

It sounds like your module_path/MODULE_PATH variables are being set to
something that doesn't include the paths configured by the shell.
In your case this should be something like /t/zz/lib/zsh/lib/zsh/4.3.4.

> FWIW, $KEYTIMEOUT was 40, and I tried setting it (via "export KEYTIMEOUT=N")
> with values of 100 and 100000, with the same result.

This is the problem that really needs explanation.  KEYTIMEOUT should
definitely make the shell wait for a following ^x.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview

Re: zsh 4.3.4: bindkey -s xx 'yyy\n' no longer works (with bindkey -v)

[Peter Stephenson]

Peter Stephenson wrote:
> Jim Meyering wrote:
> > [BTW, without --disable-dynamic, not much worked, since it couldn't
> > find any modules, e.g., zle]
> 
> It sounds like your module_path/MODULE_PATH variables are being set to
> something that doesn't include the paths configured by the shell.
> In your case this should be something like /t/zz/lib/zsh/lib/zsh/4.3.4.

Obviously there should only be one lib/zsh/ in the path.

pws


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview

Re: zsh 4.3.4: bindkey -s xx 'yyy\n' no longer works (with bindkey -v)

[Jim Meyering]

Peter Stephenson <pws <at> csr.com> writes:
> Jim Meyering wrote:
> > [BTW, without --disable-dynamic, not much worked, since it couldn't
> > find any modules, e.g., zle]
> 
> It sounds like your module_path/MODULE_PATH variables are being set to
> something that doesn't include the paths configured by the shell.
> In your case this should be something like /t/zz/lib/zsh/lib/zsh/4.3.4.

Here's what I get:

  $ echo $MODULE_PATH
  /t/zz/lib/zsh/4.3.4-dev-0

and even /t/zz/lib doesn't exist.

Re: zsh 4.3.4: bindkey -s xx 'yyy\n' no longer works (with bindkey -v)

[Peter Stephenson]

Jim Meyering wrote:
> Here's what I get:
> 
>   $ echo $MODULE_PATH
>   /t/zz/lib/zsh/4.3.4-dev-0
> 
> and even /t/zz/lib doesn't exist.

That makes it look like you didn't do "make install" from the top level
of zsh, or there was some problem with the path that prevented
installation.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview