zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <pws@ifh.de>
To: zsh-workers@math.gatech.edu (Zsh hackers list)
Subject: Re: bindkey induced coredump
Date: Thu, 12 Sep 1996 13:38:56 +0200	[thread overview]
Message-ID: <199609121138.NAA07383@hydra.ifh.de> (raw)
In-Reply-To: "Mark Hanson"'s message of "Thu, 15 Aug 1996 13:38:36 MET." <199608152038.NAA29423@acucobol.acucobol.com>

Mark Hanson wrote:
> $ zsh -f
> $ echo $ZSH_VERSION
> 3.0.0
> $ bindkey -v
> $ bindkey -r '\e[A'
> $ bindkey -r '\e[B'
> $ bindkey -r '\e[C'
> $ bindkey -r '\e[D'
> $ <ESC><ESC>
> coredump

Doesn't look like anybody else has had a go at this.

I think the following patch is right, but this had me confused for a
long time.  The confusion is all the different key binding tables.  I
think what's happening is this:  the last bindkey -r deletes the entry
for "\e" in keybindtab (which is vikeybindtab) since it now has
nothing attached to it in mainbindtab.  However it is still marked as
a prefix in altbindtab, which is used in vi command mode, which is
what the first <ESC> enters.  Hence the crash when zle tries to look
for a key representing the prefix on the second <ESC>.  (keybindtab,
as I understand it, is only used to resolve multi-key sequences and
the like.)

The answer seems to be to make sure the prefix entry is deleted in the
other bindtab.  It's not actually clear that one wants to remove all
those cursor key entries in the alternate keymap, but given there is
only one keybindtab for vi mode, that's currently inevitable.

The remaining question is what to set the key to in the other bindtab,
given that it was previously only set for a prefix.  The choices are
undefined or the same as in the first bindtab.  I picked the latter.

*** Src/zle_main.c.bind	Thu Sep  5 22:47:12 1996
--- Src/zle_main.c	Thu Sep 12 13:37:02 1996
***************
*** 991,997 ****
--- 991,1005 ----
  			}
  			(ky = (Key) keybindtab->getnode(keybindtab, s))->prefixct--;
  			if (!ky->prefixct) {
+ 			    int *otab = ops['a'] ? mainbindtab : altbindtab;
  			    tab[STOUC(*s)] = ky->func;
+ 			    /*
+ 			     * If the bindtab we are not using also
+ 			     * adds this key as a prefix, it must also
+ 			     * be reset.
+ 			     */
+ 			    if (otab[STOUC(*s)] == z_prefix)
+ 				otab[STOUC(*s)] = ky->func;
  			    if (ky->func != z_sendstring)
  				free(keybindtab->removenode(keybindtab, s));
  			}

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77330
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.


      parent reply	other threads:[~1996-09-12 12:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-08-15 20:38 Mark Hanson
1996-08-16 11:21 ` Zefram
1996-09-12 11:38 ` Peter Stephenson [this message]

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=199609121138.NAA07383@hydra.ifh.de \
    --to=pws@ifh.de \
    --cc=zsh-workers@math.gatech.edu \
    /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).