[Top][All Lists]

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

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

From: Vincent . Raffensberger
Subject: Re: [Help-nano] numlock probs since v1.0.x
Date: Fri, 25 Jun 2004 10:01:25 -0500

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

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

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

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

reply via email to

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