Re: History Up key

Re: History Up key

[Bart Schaefer]

(Relocated to -workers)

On Mar 13,  8:22pm, Zefram wrote:
> Subject: Re: History Up key
> 
> A.  It would be a bad idea to have arrow keys bound by default in vi
>     insert mode.  Emacs mode and vi command mode don't have the same
>     problems, because <esc> itself isn't bound to anything in those
>     keymaps.

Obviously, though, users want it, or all those vi clones wouldn't have put
in hacks to make it work.

> B.  Adapting the arrow key sequences to the local terminal is problematic.
>     Binding things like ^H as arrow key sequences will cause big problems,
>     so at minimum terminals where arrow keys don't send escape sequences
>     should be treated as having no arrow keys.

This suggests that any and all keybindings read from term(cap|info) should
be bound BEFORE any of zsh's regular defaults, so that e.g. if down-arrow
sends ^J, the binding to down-history is replaced by one for accept-line.

>     With that heuristic in
>     place, the only problem with adaption is the issue of programmatically
>     knowing where those bindings are.

Which should be easier with the termcap and terminfo modules ...

> C.  The documentation should contain advice on how to turn *on* key
>     bindings for arrow keys in vi insert mode.  This avoids the issue
>     of difficulty in turning off the bindings.

Should I commit my zkbd script?  If so, where -- under Misc/ ?
(See zsh-users/3563)

Re: History Up key

[Peter Stephenson]

Bart write:
> On Mar 13,  8:22pm, Zefram wrote:
> > Subject: Re: History Up key
> > 
> > A.  It would be a bad idea to have arrow keys bound by default in vi
> >     insert mode.  Emacs mode and vi command mode don't have the same
> >     problems, because <esc> itself isn't bound to anything in those
> >     keymaps.
> 
> Obviously, though, users want it, or all those vi clones wouldn't have put
> in hacks to make it work.

Yes, we get lots of complaints that arrow keys don't work, despite the FAQ.
We don't get many complaints that zsh is full of hacks.  Odd...

> > B.  Adapting the arrow key sequences to the local terminal is problematic.
> >     Binding things like ^H as arrow key sequences will cause big problems,
> >     so at minimum terminals where arrow keys don't send escape sequences
> >     should be treated as having no arrow keys.
> 
> This suggests that any and all keybindings read from term(cap|info) should
> be bound BEFORE any of zsh's regular defaults, so that e.g. if down-arrow
> sends ^J, the binding to down-history is replaced by one for accept-line.

It's a little hard to do that cleanly, since default_bindings() is optimised
to set up the single-character bindings without going through bindkey.  But
I think we can do almost the same quite easily by testing whether termcap
came up with a single character binding which is already bound.  In fact,
most single character bindings are already bound, but there are a few which
are t_undefinedkey.  This should keep the default bindings clean --- users
are on their own, as usual.

Index: Src/Zle/zle_keymap.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_keymap.c,v
retrieving revision 1.4
diff -u -r1.4 zle_keymap.c
--- Src/Zle/zle_keymap.c	2001/03/13 15:32:43	1.4
+++ Src/Zle/zle_keymap.c	2001/03/14 11:21:25
@@ -1029,6 +1029,7 @@
 add_cursor_key(Keymap km, int tccode, Thingy thingy, int defchar)
 {
     char buf[2048];
+    int ok = 0;
 
     /*
      * Be careful not to try too hard with bindings for dubious or
@@ -1042,7 +1043,18 @@
 	cursorptr = buf;
 	tputs(tcstr[tccode], 1, add_cursor_char);
 	*cursorptr = '\0';
-    } else {
+
+	/*
+	 * Sanity checking.  If the cursor key is zero-length (unlikely,
+	 * but this is termcap we're talking about), or it's a single
+	 * character which is already bound, then we don't bind it.
+	 */
+	if (!buf[0] || (!buf[1] && km->first[STOUC(buf[0])] != t_undefinedkey))
+	    ok = 0;
+	else
+	    ok = 1;
+    }
+    if (!ok) {
 	/* Assume the normal VT100-like values. */
 	sprintf(buf, "\33[%c", defchar);
     }

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: History Up key

[Zefram]

Peter Stephenson wrote:
>+	/*
>+	 * Sanity checking.  If the cursor key is zero-length (unlikely,
>+	 * but this is termcap we're talking about), or it's a single
>+	 * character which is already bound, then we don't bind it.
>+	 */
>+	if (!buf[0] || (!buf[1] && km->first[STOUC(buf[0])] != t_undefinedkey))
>+	    ok = 0;
>+	else
>+	    ok = 1;
>+    }
>+    if (!ok) {
> 	/* Assume the normal VT100-like values. */
> 	sprintf(buf, "\33[%c", defchar);
>     }

Rather dodgy logic here.  Surely we should be doing all-terminfo arrow
keys or all-VT100 arrow keys, not some combination.

And if we're going the way of arrow keys being bound by default, let's
have some documentation on how to remove those bindings, and let's make
it feasible.  With this kind of logic in place (whether on a key-by-key
basis or affecting the whole set), simply unbinding the terminfo-derived
key sequences isn't sufficient.  In fact, with the logic in the form
you propose above, there is no way to determine whether a binding of
a single-character arrow-key sequence comes from the arrow key or from
the default map, short of knowing the default map.

I suggest in any case a simplification that will ameliorate this problem:
just don't bind single-character arrow-key sequences, rather than only
avoiding such sequences that are already bound.

-zefram

Re: History Up key

[Zefram]

Bart Schaefer wrote:
>Obviously, though, users want it, or all those vi clones wouldn't have put
>in hacks to make it work.

Yes, we should make it easy to get the arrow key bindings.
It should be easy to have either behaviour, whatever the default is.
We should be aiming for a situation where the interested user only
needs to add a single command, either "create_arrow_key_bindings" or
"remove_arrow_key_bindings", in their .zshrc -- the command should be
a zsh function in the distribution.

>>     With that heuristic in
>>     place, the only problem with adaption is the issue of programmatically
>>     knowing where those bindings are.
>
>Which should be easier with the termcap and terminfo modules ...

Easier, but putting in heuristics such that arrow key sequences from
terminfo may or may not be bound makes it more difficult.  If arrow keys
are bound by default, then the shell code to turn them off is going to
have to exactly duplicate the logic of the C code that turns them on.
Btw, what happens to these bindings if $TERM gets changed?

This difficulty with turning off the bindings is why I suggest that the
bindings should be off by default -- it's easier to have only one copy
of the logic, in some shell code that creates the bindings.

>Should I commit my zkbd script?  If so, where -- under Misc/ ?

It looks useful.  Misc makes some kind of sense, but I'd put it under
Functions.

-zefram

Re: History Up key

[Bart Schaefer]

On Mar 15,  7:27pm, Zefram wrote:
} Subject: Re: History Up key
}
} >Should I commit my zkbd script?  If so, where -- under Misc/ ?
} 
} It looks useful.  Misc makes some kind of sense, but I'd put it under
} Functions.

OK, I've just committed a much-cleaned-up version under Functions/Misc.
(The version in users/3563 was downright broken; I've been writing too
much Perl lately and used the wrong assoc-array syntax.)

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net