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

[David Lawrence Ramsey]

--- 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.