bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: readline: edit (mode:vi) means eol unreachable


From: Hugh Sasse
Subject: Re: readline: edit (mode:vi) means eol unreachable
Date: Mon, 5 Feb 2007 14:28:38 +0000 (WET)

On Mon, 5 Feb 2007, Chet Ramey wrote:

> Hugh Sasse wrote:
> 
> >> provide the right entries that allow the key sequences output by the
> >> arrow keys to be bound to the motion commands you want.  You can do
> >> this yourself; the easiest way to find out the key sequence output by
> >> an arrow key is to use `cat -v'.
> > 
> > Where should I look to see how the correct "out of the box" behaviour
> > is defined?  If I'm to modify PuTTY's terminfo till it works correctly,
> > I will need to know what the definition of "correct" is.   I know that
> > bash allows subsequent key bindings, and that I can customise things
> > afterwards.
> 
> I'm not sure I understand the question.  If the termcap/terminfo entries

The question is about the vi edit mode for a correctly configured
terminal, with no personalization.  Should the cursor keys take me
out of insert mode, or leave me in insert mode (like vim), and
should I be able to move to beyond the last character (after having
moved left) so that I can append more text?  This is the behaviour I
get without any .inputrc at all, though the editing mode is then
emacs.  Considering the use case of someone who doesn't know about
.inputrc and what their sysadmin may have given them, I'd expect
emacs and vim behaviour to be identical, until someone entered a
specific vim/emacs command.  But that's probably naive, so
presumably this is specified somewhere? 

> contain the key sequences output by the arrow keys (in termcap, they're
> the `ku', `kd', `kr', and `kl' capabilities), bash will bind them and use

> them `out of the box'.  I guess the answer is to find the appropriate key
> sequences and make sure they're assigned to the terminfo equivalents.

Quoting Sun's man terminfo:

     Variable               Name       Code      Description

     key_up                 kcuu1      ku        KEY_UP, sent by  terminal  
up-arrow
     key_down               kcud1      kd        KEY_DOWN, sent by terminal
     key_right              kcuf1      kr        KEY_RIGHT, sent by terminal
     key_left               kcub1      kl        KEY_LEFT, sent  by  terminal  
left-

So I have: 

:r! egrep  'kcu(u|d|f|b)1' ~/terminal/putty.ti
        kcud1=\E[B, kend=\E[4~, kent=\EOM, 
        kcub1=\E[D, kmous=\E[M, knp=\E[6~, 
        kpp=\E[5~, kcuf1=\E[C, kDC=\E[3$, 
        kRIT=\E[c, kcuu1=\E[A, rmkx=\E>, 

Which when put through tic ends up in my $TERMINFO directory, and is 
picked up because I have no other entry called putty on the system.
Also tic doesn't complain about using names rather than codes as
$(man terminfo) calls them, and my cursor keys work as I'd expect.
So why am I getting different behaviour between this and an xterm?

:r! infocmp -I putty
#       Reconstructed via infocmp from file: /home/hgs/TERMINFO/p/putty
putty|PuTTY (a free Win32 telnet/ssh client),
        am, bce, eo, km, mir, msgr, xenl, xon,
                [...]
        kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
                [...]

All this could be complicated by the cursor keys emitting Escape, 
which could interact horribly with vi mode!
> 
> Chet
> 

        Thank you,
        Hugh




reply via email to

[Prev in Thread] Current Thread [Next in Thread]