[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Arrow keys in nano
On 09/02/2013 16:53, Helmut Karlowski wrote:
So I propose to remove that IEXTEN to XKEY mapping in the MiNTLib. And
always keep XKEY enabled, like Linux.
That will fix nano on the BIOS console and TosWin tw52.
That means to me transporting a linux-bug to freemint, am I right?
I don't think so.
Back to the old UNIX days with physical text terminals, there was no such
concept as scancodes. Characters produced ASCII codes, while function keys
(including arrows) produced escape sequences. Those escape sequences were
produced by the terminal itself.
On the other side, the TOS do not generate ASCII codes for the arrows, a
compatibility layer has to be introduced somewhere.
I believe that the IEXTEN flag is related to the kernel terminal driver, to
enable or disable the generation of new pseudo-characters. But the arrows
are not pseudo-characters in Linux, this is why I believe that the current
MiNTLib behaviour is wrong. This is proven by my testcase.
But Esc A is also the FreeMiNT kernel code for the up arrow! So there is a
conflict between the kernel escape sequences and the nano shortcuts. There
is no way to differentiate them.
Sure it is! Any halfway good program measures the time-gap between the Esc
and the A as I already mentioned. There is no conflict when it's done right.
You are confusing 2 things:
- when Esc and the next char are received quickly, ncurses handles them as a
single function key
- when the exact same characters are received slowly (let's say, more than
second after Esc), then ncurses handles all the characters as individual ones
This is why the Esc key alone is slow to answer in ncurses applications
(such as demo_defkey): because ncurses waits to see if there is another
character just after, to eventually result in a function key instead of the
Esc key.
Back to the initial problem:
I test using ^V in bash to see the actual escape codes.
- On FreeMiNT BIOS console, when I press the up arrow, I get ^[A
- On Cygwin with MinTTY (a modern terminal compatible with xterm), I turn
Caps Lock on and I type Alt+A: I get ^[A
In both cases, the codes are the same. They are generated quickly. So there
is no way to differentiate them.
The only surprising thing is what happens in nano.
When typing _slowly_ Esc then V for example, it does the expected M-V
function, while it should produce the Esc function (whatever it is) then
type V. So I believe that nano uses further hacks to handle the shortcuts,
which would not be surprising regarding to that get_escape_seq_kbinput() stuff.
1) Fix TosWin2 for tw100 (see other thread)
2) Fix the MiNTLib to remove the IEXTEN to XKEY mapping
And nano will work fine in any case (after recompilation).
You'd have to test this with all currently working programs before.
Indeed, even though the solutions are clean, they can have adverse effects
to the programs accustomed to the wrong behaviour.
What do we do for the release?
BTW, is there an 1.18 branch for the MiNTLib and TosWin2?
--
Vincent Rivière