Re: [Help-nano] numlock probs since v1.0.x

[Vincent . Raffensberger]

I'm sorry if you didn't get my last
response.  We were having major mail trouble here last week and I
think our illustrious mail guy just dumped the queues until things "fixed
themselves"...  :(

I had installed the latest version of
putty to test this.  That was version is 0.54.  I didn't look
into any of it's settings other than changing the terminal type.  I
had tried both vt100 and xterm.

I downloaded the current cvs again this
morning to be up to date and tried again.  Here's the version info:
 GNU nano version 1.3.2-cvs (compiled
10:30:01, Jun 25 2004)
 Email: address@hidden  
 Web: http://www.nano-editor.org/
 Compiled options:

With that version, 0-3 and '.' do nothing.
 I'm not certain, but '+' appears to be ^C.  The other keys are
the same as before and the actual function keys work as expected.

I hadn't checked before, but the problem
also exists in other applications such as vi, but not in any shells.  
In vi the output results are different
for 0-3 and '.':  0=end,1=home, 2=insert, 3=kpageup, '.'=kpagedown.

When I noticed the issue popup between
nano v1.0 and the current versions, I assumed it was an issue with nano.
 It's defiantly an issue with these windows terminal apps.

As suggested before, setting 'set keypad'
in .nanorc takes care of the problem.  Can that only be set via the
nanorc file?  It may be more convenient to have a command line switch
or compile option.
I imagine a lot of people use either
teraterm or putty on a regular basis.  It may be helpful to them to
add this info to the manpage, docs or FAQ.

Thanks for all of your help.

address@hidden (David Lawrence Ramsey)
Sent by: address@hidden

06/24/2004 04:41 PM

Please respond to
address@hidden

To	address@hidden
cc	address@hidden
Subject	Re: [Help-nano] numlock probs since v1.0.x

--- address@hidden wrote:
>I had tested with 1.3.2 before.  The numlock row does function
as 
>F1-F4. I checked out the cvs this morning at 11:00 and got slightly
>different results with that build. That version was 1.3.2-cvs.  The
>numlock row still acted like F1-F4.  0-4 keys did nothing.  4-9
keys 
>were still "^M" "^N" "^O" "^Q"
"^R" "^H".  Let me know if you want me 
>to try or test anything else.  I've been using this since it was
tip 
>and am glad to get the chance to help out.

Thank you.  I've looked into this some more, and I've figured a few
things out.  I can't help you much with TeraTerm, as (a) it's under
a 
non-free license that e.g. forbids distributing modified versions 
without permission; (b) it's Windows-only, and I know very little about
Windows-specific code; (c) the homepage that I looked up via Google 
hasn't been updated since 1999, so it looks to be unmaintained; and (d)
I don't have access to a Windows box with development tools to build it
on in any case.  However, I think I can help you with PuTTY to an
extent.

First off, what version of PuTTY are you seeing this on?  The assigning
of the top row to F1-F4 in keypad mode is apparently hardcoded in PuTTY,
both in the Windows and Unix ports.  The two share little code in
terms 
of key interpretation, though, so the fact that the Unix port in PuTTY
0.54 (the latest version; maybe you should try it if you're using an old
version?) has the keypad, except for the top row, working as expected on
my box doesn't help much.  Also, does setting $TERM to "putty"
affect 
anything?

There's another way of mapping the keypad that's different from the one
I mentioned before, but is even more compatible with the VT100 keypad 
and even less compatible with the IBM PC keypad.  It's apparently
designed for old termcap-based systems:

   _____________________
  | F1 | F2 | F3 | F4   |
  |    |    |    |      |
  |____|____|____|______|
  | F9 | F10| F0 | -    |
  |    |    |    |      |
  |____|____|____|______|
  | F5 | F6 | F7 | F8   |
  |    |    |    |      |
  |____|____|____|______|
  | A1 | B2 | A3 |      |
  |    |    |    | enter|
  |____|____|____|      |
  |    C1   | C3 |      |
  |         |    |      |
  |_________|____|______|

Now the A1, B2, A3, C1, and C3 keys are properly laid out on the '7', 
'9', '5', '1', and '3' keys instead of the '1', '2', '3', '0', and '.'
 
keys as shown above, and one of the changes in 1.3.2-cvs was to 
interpret them.  (The CVS version has only added interpretation of
keys 
and hasn't removed any, so if the keys were generating something in 
1.3.2, they should be generating something now.)  Since I was going
by 
the proper layout, I was interpreting them as Home, PageUp, [nothing],
End, and PageDown.  Keeping this in mind, it's occurred to me that
if 
you're testing the 0-4 keys on an empty file, they'll appear to do 
nothing.  What do they, and the '.' key, do when you test them on
a few 
lines of text?

I've found out that under ncurses at least, KEY_F(5), KEY_F(6), 
KEY_F(7), KEY_F(9), KEY_F(10), and KEY_F0 are ^M, ^N, ^O, ^Q, ^R, and ^H
when cut down to ASCII range.  However, they should be interpreted
(except for KEY_F0) instead of passed through untranslated as they 
appear to be here.  From this, I'm guessing that PuTTY and TeraTerm
are 
mapping the keypad as in the diagram.  Just so I know for certain,
though, do you get KEY_F(8) (^P) when you press '+' on the keypad, and
do the actual function keys work as expected?

I've tried setting my terminal type to a terminal that maps the keypad
as in the diagram (and there are several terminal types like this), and
I don't have any problems with its not interpreting the 0-4 keys 
properly under xterm.  However, I'm not sure why this is happening.
 As 
far as I can tell at the moment (barring your answers to the above 
questions), this all stems from a keypad mapping problem that needs to
be fixed on PuTTY's end.

There's a workaround that you can use for the time being, though.  One
of PuTTY's options is to not allow applications to switch into 
application keypad mode.  If you turn that option on, things should
work 
about as well as they can with the escape sequences nano understands.  
Note that there are a few key conflicts between different terminal 
types, so absolutely every key may not work as expected.

The key conflict problem is one of the reasons why I switched nano 1.3.x
to use keypad mode exclusively.  If the keys are properly translated,
you don't need to worry about any escape sequences and/or conflicts 
between them, which means that you can support more terminal types.  (Of
course, I've still had to add support for escape sequences for those 
cases where the keys aren't translated correctly due to a bad 
termcap/terminfo entry, or for when there are no corresponding keypad 
values for a given set of keys.)  Also, importantly, mouse input will
only work if keypad mode is on.  If I remember correctly, if you try
to 
run nano 1.2.x with -K and -m, -m overrides -K and the keypad gets 
turned on.

Thanks for your patience.


_______________________________________________
Help-nano mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/help-nano