[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: David Lawrence Ramsey
Subject: Re: [Help-nano] numlock probs since v1.0.x
Date: Fri, 25 Jun 2004 18:08:58 +0200
User-agent: Mutt/1.5.6+20040523i

--- Vincent Raffensberger wrote:
>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"...  :(

No problem.  I've been having some email problems myself lately.  I 
think I did get your last response, though.

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

Did you also try "putty" yet?

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

Okay; it's apparently not generating anywhere near the proper values if 
this is happening.

>I hadn't checked before, but the problem also exists in other 
>applications such as vi, but not in any shells.
At least that's consistent.  The shells don't turn on application arrow 
key mode or application keypad mode, after all.

>In vi the output results are different for 0-3 and '.': 0=end,1=home,  
>2=insert, 3=kpageup, '.'=kpagedown.

Hmmm.  I'm just about stumped by now.

>When I noticed the issue popup between nano v1.0 and the current 
>versions, I assumed it was an issue with nano.  It's definitely an 
>issue with these windows terminal apps.
>As suggested before, setting 'set keypad' in .nanorc takes care of the 

But only in 1.2.x, unfortunately.  I suppose I could add it back to 
1.3.x, but I'd prefer to do that only as a last resort for the reasons I 
stated before.  Also, it can't go into 1.3.2-cvs now, mainly because (a) 
it's been delayed for far too long, and (b) as you've said, it's most 
likely not a problem on nano's end.  If I put the keypad option back in,  
it'll be in 1.3.3-cvs at the earliest; sorry.

In the meantime, as I mentioned before, you can keep keypad mode from 
being turned on at all via one of PuTTY's options.  Or you could try 
typing in the keys via verbatim input mode in 1.3.x (Meta-V followed by 
the key), which temporarily turns the keypad off, although that may not 
be practical if you type a lot with the numeric keypad.

Personally, however, in the interests of not having to put in too many 
hacks for broken terminal emulators, I'd prefer that PuTTY and/or 
TeraTerm were fixed.  PuTTY sets $TERM to xterm, after all (instead of 
"putty", which it probably should be doing, much as rxvt should set its 
$TERM to "rxvt"), so it should probably try to be a little more 
xterm-compatible.  (As for TeraTerm, I don't know what to do, unless 
someone else takes over maintaining it and is willing to do something 
about this.)  You could try sending the PuTTY maintainers a bug report 
about this, or I could if you don't have time for it.

>Can that only be set via the nanorc file?  It may be more 
>convenient to have a command line switch or compile option.

You can also use the -K or --keypad command line option in nano 1.2.x.

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

I'll look into it.  I can probably use some of the same text from the 
old entry about the NumLock glitch.

>Thanks for all of your help.

No problem.  Here's hoping that this mess finally gets worked out  
sometime soon.

reply via email to

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