Key bindings in Zsh?

Key bindings in Zsh?

[Brian P. Barnes]

Hi,

My insert/delete/home/end/pgup/pgdn keys do not work in Zsh. They either
give me a squiggle ('~'), a beep or do the wrong thing:
    Insert, pgup, pgdn -> ~
    delete                        -> backspace
    home, end                 -> beep

The keys work in other tools I use including Vim and Netscape so I don't
think I want to alter my Xmodmap.

The Zsh manual makes a glancing reference to "use zle -N" in reference
to using user-defined widgets implemented as shell functions to execute
key mapping.  There appears to be no documentation for this function
either in the manual or the FAQ. Deja News reports one hit on "zle -N"
which is in reference to a Debian Linux bug and a www search gives only
pointers to the FAQ.

I tried adding the following to my .zshrc file: `zle -N END end-of-line`
which did nothing. Having just a beep to deal with, I didn't know which
key to map end-of-line to in an xterm. In an aixterm, instead of a beep,
I get a "46q" on my command line and I tried `zle -N 46q end-of-line`
which also did nothing.

Are there more examples of key mapping which I have missed?

I am on an IBM RS/6000 using AIX 4.3.2 and either an X11 xterm or an
aixterm. Would somebody using Zsh on AIX who has the use of these keys
please tell me how they accomplished it?

Thank you,

    Brian

Re: Key bindings in Zsh?

[Bart Schaefer]

On Aug 26,  9:30am, Brian P. Barnes wrote:
} Subject: Key bindings in Zsh?
}
} My insert/delete/home/end/pgup/pgdn keys do not work in Zsh. They either
} give me a squiggle ('~'), a beep or do the wrong thing:
}     Insert, pgup, pgdn -> ~
}     home, end                 -> beep

What exactly do you think they should do?

Zsh has generally avoided the issue of bindings for things like the arrow
keys, the keypad, and function keys because terminals and keyboards vary
so widely and termcap/terminfo have historically been untrustworthy.  The
vt100-compatible arrow-key bindings are all that's ever been bound by
default.

There has been some discussion of initializing more from the terminal
databases, but the question of what they should mean remains -- what is
a "page" at a command line prompt?  Does "Home" go all the way to the
beginning of the history, or (as you seem to expect) just to beginning
of line?  Etc.

}     delete                        -> backspace

That one's intentional; many keyboards have delete and backspace swapped,
so zsh has always made them behave identically.

} The keys work in other tools I use including Vim and Netscape so I don't
} think I want to alter my Xmodmap.

Zsh is not an X11 program and does not receive X11 keyboard events; it
gets whatever sequence of characters the terminal or terminal emulator
decides to send it.  So your X mappings and what Netscape does are both
largely irrelevant.

} The Zsh manual makes a glancing reference to "use zle -N" in reference
} to using user-defined widgets implemented as shell functions to execute
} key mapping.  There appears to be no documentation for this function

Which zsh manual?  The texinfo doc for 3.1.6 has an entire section "The
zle Module" devoted to this, in which you'd have discovered that what you
want is not "zle" anyway, but rather "bindkey".  If you're using 3.0.6 or
earlier, you want the section "Shell Builtin Commands", but 3.0 doc should
not mention "zle -N" at all.

In both cases, the set of actions (widgets) that can be bound to keys are
described in the "Zsh Line Editor" section.

You could also have tried searching the archives of this mailing list at
<http://www.zsh.org/mla/>.

} I tried adding the following to my .zshrc file: `zle -N END end-of-line`

That creates a new zle "widget" named END which calls the function named
end-of-line when the key to which it is bound is pressed.  It doesn't bind
it to any key, though: you need "bindkey" for that.

You probably want something in .zshrc like

	case $TERM in
	xterm)
	    bindkey '\eOH' beginning-of-line
	    bindkey '\eOF' end-of-line
	    bindkey '\e[2~' overwrite-mode
	    bindkey '\e[5~' beginning-of-buffer-or-history
	    bindkey '\e[6~' end-of-buffer-or-history
	    ;;
	aixterm)
	    # similar commands but with aixterm sequences
	    ;;
	# and so on for other terminal types
	esac


-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Key bindings in Zsh?

[Bart Schaefer]

I hope you don't mind that I've Cc'd this to zsh-users.  Having taken as
long as I did to write it, I'd rather it get seen by more people who might
be interested.

On Sep 1,  2:01pm, Brian P. Barnes wrote:
> Subject: Re: Key bindings in Zsh?
> 
> For something as simple as editing a command on the command line, I hate
> having to use vi commands.

I'm not sure what vi has to do with this, unless you mean that you use the
vi mode keybindings in zsh rather than the emacs ones.  You should mention
these details when you send questions.

> I just use word processor type editing. It's nice
> if the home takes you to the start of the command. Right now, I have that
> function to the next key over, page-up, because I just get a beep from the
> home key. Similarly, end should send you to the end of the command. Insert
> should toggle insert/overwrite mode.

The example bindkey commands I included should have set that up (for emacs
keybindings).  If you're using the vi bindings, then it's trickier, because
of the special handling of ESC to switch from insert to command modes.

> Delete should delete the character over
> the cursor (not backspace over the previous character).

Not all word processors do that; in fact, the most common Unix editors
e.g. emacs and the original vi do not; the original vi mapped backspace
and delete to the same thing when the terminal driver erase key was
bound to delete, and simply beeped at the delete key when the terminal
driver erase was bound to backspace.

Further, not everyone has a PC-101 keyboard, and people are more used to
touch-typing than to looking at the labels on their keycaps, so it's nice
(for most of us) not to be surprised when the key at the upper right of
the main alphabetic key area happens not to say "Backspace".

There is no "right way" that zsh could preconfigure this; somebody would
complain no matter what.  That's why there's "bindkey" and why zsh reads
all those init files.

> It would be cool if pageup/pagedown scrolled the contents of the zsh window
> up or down just like dragging the scroll bar does. I used to use an HP-9000
> that was setup that way and it was very handy.

Are you using a Linux console or an xterm window?  If so, try shift-pageup
and shift-pagedown.

Note, however, that zsh is not interpreting those keystrokes.  You seem to
have a misunderstanding of the way shells and terminal emulators work.  It
is the terminal emulator that captures all the output and lets you scroll
back through it, not zsh, and there's no way for zsh to receive a key and
then tell the emulator to scroll its buffer.  Instead you have to make the
emulator capture the key without ever sending it to zsh, and respond by
scrolling the buffer (note that the insertion point cursor does not move
when this happens).  This means, for example, changing the resources for
your xterm, not adding bindings to zsh.

When you're running an editor like VIM, the situation is different.  Now
the editor really is buffering all the text, and can scroll back and forth
through it and move the insertion point arbitrarily.  Zsh does this when
(and only when) you are editing a command line; once the command begins
executing, zsh gets completely out of the way and lets the command write
directly to the terminal and read directly from it.  If it didn't do this,
commands like VIM that want to draw their own output all over the screen
would compete with the shell for control of what the screen looks like.

HP-9000 terminals, by the way, are a weird case where the terminal does
seem to move the insertion cursor around, but only programs that have been
specially designed to work with HP terminals can figure out where the input
is actually going.  This is a holdover from mainframe computer days where
a single huge computer had hundreds of identical terminals all bought from
the same vendor.  (Can you say AS/400?)

> I did find some documentation on bindkey and fixed a few of the mapping
> issues myself. The ones I can't figure out are the ones that just beep or
> give a ~.  If I assign the ~ to some useful function, Insert, pgup, pgdn,
> which all give squiggles, would all do the same thing.

This is almost certainly because you are using vi mode mappings.  What is
really happening when you press those keys is that zsh receives the a
sequence of characters that begins with an ESC.  This kicks you out of vi
insert mode and into command mode; the rest of the sequence is then taken
as vi commands.

You need to use "bindkey -v ..." and include the entire escape sequence
to get this to work right.  Try this:  On the command line, first type
control-v (which usually means "quote the next character").  Then press
one of those keys that beeps at you.  You'll probably see ^[q56~ or some
such; the ^[ means ESC.  So then you use

	bindkey -v '\eq56~' vi-beginning-of-line

(or whatever, I'm imagining Home is what sends that sequence).  Repeat for
whatever other keys you want bound.

> VIM handles every key exactly as labeled as does every other modern
> (non-curses, non-vm) interface I use, except for Zsh.

I don't know what you mean by "non-vm" but zsh *is* in effect a curses
interface.  So is VIM, actually, unless you're running the X11 version that
starts its own window.

A native X11 program like xedit or Netscape or xterm receives a single X
"event" for every key you press.  This "event" includes a complete state
of the keyboard, i.e., which of the right/left control/shift/alt/meta keys
were held down, whether caps-lock is on, etc.  The X11 application then
decides what to do with that event.  In the case of xterm, what it does
is consult a mapping table that translates the event into a series of
characters (bytes), and then sends those bytes to the program running
inside the xterm, exactly as if you had typed them directly.  For keys
like a, b, c, ... or shift-A, shift-B, shift-C, ... a single ASCII byte is
normally sent ('a', 'b', 'c', ..., 'A', 'B', 'C', ...).  For function keys
like insert, home, pageup, F11, etc. a _sequence_ of bytes is sent; e.g.
on an xterm, pageup normally sends ESC, '[', '5', '~'.  An aixterm does
the same thing, but sends different sequences for the same keys.

Many of the combinations of control/alt/meta with other keys simply have
no mapping at all in the xterm or aixterm tables.  In those cases, either
the emulator sends nothing at all to the program running inside it, or
the unknown modifier keys are thrown away until it finds something it
does recognize and then the sequence for that is sent.  So it often is
completely impossible to bind zsh actions to certain key combinations,
because the terminal emulator can't or won't tell zsh exactly what keys
were pressed.

What editors like VIM do is use a database called "termcap" or another
one called "terminfo" (depends on what's installed) to reverse-map the
sequnces of bytes *back* to the corresponding keys again.  Such editors
also send special "terminal initialization" sequences to be sure that
the terminal emulator is in the correct state before they begin to get
input from it, and similar sequences to restore the previous state when
they are finished.  Zsh could be modified to look up the initialization
sequences and reverse mappings and set up the terminal just like an
editor; but it's a lot of overhead and much more easily accomplished by
personalized bindkey commands, given the inevitable disagreement about
exactly how "a word processor" behaves.

Good luck with your keybindings.



-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com