From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: zsh-workers-request@euclid.skiles.gatech.edu Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by coral.primenet.com.au (8.7.6/8.7.3) with ESMTP id GAA16879 for ; Thu, 28 Nov 1996 06:13:42 +1100 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id NAA09857; Wed, 27 Nov 1996 13:50:23 -0500 (EST) Resent-Date: Wed, 27 Nov 1996 13:50:23 -0500 (EST) To: Zefram cc: schaefer@brasslantern.com, zsh-workers@math.gatech.edu Subject: Re: Vi insert-mode cursor key bindings. In-reply-to: Your message of "Tue, 26 Nov 1996 18:09:00 +0000." Date: Wed, 27 Nov 1996 18:21:46 +0000 Message-ID: <19276.849118906@dis.strath.ac.uk> From: Duncan Sinclair Resent-Message-ID: <"01GpD3.0.xP2.lr8do"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2491 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Zefram writes: >It does the right thing in that case. But [A is a likely >mistyping of some reasonable editing actions. In any case, I find the >delay annoying: if I pressed , it should take the action for >immediately. With no escape sequences around, this is acheivable. How long is the delay? One second is probably too long. Maybe 200ms would be OK. I don't know how long a delay nvi uses but it does seem a little too long. Of course, the delay should be set according to the value of "BAUD". (Though baud rates are rarely important these days...) >No. Actually, I usually use a couple of Lear Siegler ADM 3E >terminals. These generate ^H for left, ^J for down, ^K for up[1] and >^L for right. Some programs can handle this (vi for one), but many get >confused. I occasionally use an ADM 5A, with the same behaviour. Maybe it's just me, but I always thought this set to be a fairly obvious choice. >>If we're going to add default bindings for the cursor keys, we should >>do it right -- we should read the term{cap,info} database and add the >>binding for what it says the arrow keys generate, not just hardwire to >>the vt100/ANSI sequences. (Most vi that I've used actually map both >>the ANSI and terminfo arrow keys, though not in insert mode.) > >Yes, we should. But we should watch out for weird terminals like mine, >and be careful not to squash anything otherwise bound. Personally I >would miss using right arrow to clear the screen, if it were to be >rebound. That's true. Another thing to watch for is termcap initialisation and the difference between "[A" and "OA". >>From the xterm termcap entry: ku=\EOA: kd=\EOB: kr=\EOC: kl=\EOD: But the zsh bindings are: "^[[A" up-line-or-history "^[[B" down-line-or-history "^[[C" forward-char "^[[D" backward-char These are different because the termcap database is only correct after the "ti" string has been sent - "ti" is the "string to begin programs that use termcap". It has a partner - "te". So, shouldn't we be using "ti"? No. Because on an xterm the "ti" string does this: In VT102 mode, there are escape sequences to activate and deactivate an alternate screen buffer, which is the same size as the display area of the window. When activated, the current screen is saved and replaced with the alternate screen. Saving of lines scrolled off the top of the window is disabled until the normal screen is restored. The termcap(5) entry for xterm allows the visual editor vi(1) to switch to the alternate screen for editing and to restore the screen on exit. - xterm man page I don't think this is what is wanted for an interactive shell. But then someday you'll find a terminal that won't play unless you send the "ti" string. Any thoughts on this? (Apart from lynching Bill Joy for giving us all this nonsense.) Cheers, Duncan.