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

2007-02-05 Thread Hugh Sasse
On Thu, 1 Feb 2007, Thomas Dickey wrote:

> Hugh Sasse <[EMAIL PROTECTED]> wrote:
> 
> > I see that a terminfo entry for PuTTY is on the wishlist. So meanwhile
> > I've asked them to re-examine this.  
> 
> On PuTTY developer's wishlist, I assume.

Yes, sorry about that ambiguity.
> 
> ncurses has had a "putty" terminfo for a few years (iirc, the example
> given on PuTTY's website has some problems).

Thanks, I'll have a look at that and see what further info I can dig out.
> 
Thank you,
Hugh


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash


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

2007-02-05 Thread Hugh Sasse
On Sun, 4 Feb 2007, Chet Ramey wrote:

> Hugh Sasse wrote:
> > On Thu, 1 Feb 2007, Chet Ramey wrote:
> 
> > If I invoke an xterm from my session, using it with Exceed
> > version 8, I get a different kind of bug, namely that moving left
> > with the cursor key takes me out of insert mode and removes the
> > rightmost character from the display. 
> 
> This isn't a bug.  It just means that the termcap/terminfo entry doesn't

Sorry, that was badly phrased.

> 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.
> 
> Chet
Thank you,
Hugh


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash


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

2007-02-05 Thread Chet Ramey
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
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.

Chet


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
   Live Strong.  No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash


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

2007-02-05 Thread Hugh Sasse
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  kuKEY_UP, sent by  terminal  
up-arrow
 key_down   kcud1  kdKEY_DOWN, sent by terminal
 key_right  kcuf1  krKEY_RIGHT, sent by terminal
 key_left   kcub1  klKEY_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


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash