zsh-workers
 help / color / mirror / code / Atom feed
From: Duncan Sinclair <sinclair@dis.strath.ac.uk>
To: Zefram <zefram@dcs.warwick.ac.uk>
Cc: schaefer@brasslantern.com, zsh-workers@math.gatech.edu
Subject: Re: Vi insert-mode cursor key bindings.
Date: Wed, 27 Nov 1996 18:21:46 +0000	[thread overview]
Message-ID: <19276.849118906@dis.strath.ac.uk> (raw)
In-Reply-To: Your message of "Tue, 26 Nov 1996 18:09:00 +0000."


Zefram writes:
>It does the right thing in that case.  But <ESC>[A is a likely
>mistyping of some reasonable editing actions.  In any case, I find the
>delay annoying: if I pressed <ESC>, it should take the action for <ESC>
>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 "<ESC>[A" and "<ESC>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.


             reply	other threads:[~1996-11-27 19:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-11-27 18:21 Duncan Sinclair [this message]
  -- strict thread matches above, loose matches on Subject: below --
1996-11-26 12:43 Duncan Sinclair
1996-11-26 12:53 ` Zefram
     [not found]   ` <zefram@dcs.warwick.ac.uk>
1996-11-26 17:33     ` Bart Schaefer
1996-11-26 18:09       ` Zefram
1996-11-27  0:40         ` Bart Schaefer

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=19276.849118906@dis.strath.ac.uk \
    --to=sinclair@dis.strath.ac.uk \
    --cc=schaefer@brasslantern.com \
    --cc=zefram@dcs.warwick.ac.uk \
    --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).