Re: [BUG(?)] Cannot learn keypad symbols in mc-4.6.0-pre2

[Pavel Roskin <proski gnu org>]

> Well, we're late a bit...
> Between the e-mail messages I've rebooted my machine, plus played a bit
> with "Learn keys" dialog. So, now I see that the problem is somehow
> disappeared. Presently, the output of dd command is the same for root
> and normal user:
> --- cut ---
> ^[Ol
> ^[OS
> ^[OR

That's better, because mc can distinguish the keypad keys.

> If I'll encounter the same problem again, I'll immediately capture an
> output of the dd command. By the way, could you explain what does this
> "echo -ne '\e[?1h\e='" mean? mc stops understanding of arrow keys after
> the command.

According to http://ftp.xfree86.org/pub/XFree86/4.2.1/doc/ctlseqs.TXT

CSI ? Pm h     DEC Private Mode Set (DECSET)
		 Ps = 1  -> Application Cursor Keys (DECCKM)

ESC =	       Application Keypad (DECPAM)

This is emitted by application_keypad_mode().  mc does something strange
with application_keypad_mode() and numeric_keypad_mode() dependent on
whether alternate_plus_minus is set.  Both functions are only used on
xterm and Linux console.

I'll not be surprised if the keypad keys start working differently after
running a command or using Ctrl-O to switch to the subshell and back.  The
code is very unclear.

All this need to be cleaned up some day.  If you can help with it, you are
welcome.

> Just found how to reproduce the described problem:
> mc, Ctrl-O, mc, F9, 'Options->Learn keys', keypad's +-*.

Honestly, I didn't see that when I wrote about Ctrl-O above!

I believe that mc should always be in the same mode when the mc GUI
(panels, viewer, editor) is active.  It should set the same mode when
switching to the application and it should restore the original mode when
switching back.  I guess at least one of those steps is implemented
incorrectly.  It seems that mc fails to set a certain mode on startup if
it matters whether it's "inner" or not.

> May be this was the source of my issue. I should be more accurate before
> reporting bugs. The type of user account is of no importance here, and
> may be this not a bug.

Good to know.

-- 
Regards,
Pavel Roskin