[MiNT] Arrow keys in nano

[Vincent Rivière <vincent.riviere@freesbee.fr>]

On 07/02/2013 22:14, Helmut Karlowski wrote:
> So you'll have to configure the cursor-keys for nano too

nano uses ncurses (not readline), so provided that TERM is set properly and 
the terminfo database it at the right place, everything should work fine. 
But it does not, because of multiple bugs everywhere.

I have deeply analyzed the situation.
Fortunately, it is unrelated to my recent RAW+CRMOD patch :-)

Basically it is related to:
- the TosWin2 bug in tw100 mode (see other thread)
- the IEXTEN flag in termios
- the XKEY flag in the kernel
- there is a conflict between tw52 arrow codes and nano shortcuts (as Helmut 
suspected).

I didn't find anything wrong in ncurses.

Now the long story.

1) nano disables the termios IEXTEN flag (unlike vim).
Once again, Helmut had the good intuition.
See src/nano.c, in disable_extended_io().
I'm unsure why nano does that.

2) In the MiNTLib, termios/tcsetattr.c
termios' IEXTEN is translated to the kernel Fcntl's XKEY.
That XKEY flag enables the generation of ascii sequences on arrow keys (such 
as Esc A, etc.)

When IEXTEN is unset, then XKEY is removed.
I think that it's wrong.
See the attached testcase. It disables the IEXTEN flag, and waits for a few 
keys. On Linux, the arrows still produce escape sequences. On FreeMiNT (both 
BIOS console and TosWin2 tw52 mode), this does not occur anymore.

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.

If we agree to do that, I will provide a patch.

3) TosWin2 translation in tw100 mode
The kernel generates arrow escape sequences such as ^[A (means Esc A). When 
TosWin2 is in tw52 mode, those codes go straight to the application. But 
when TosWin2 is in tw100 mode, the GEM scancodes are translated to different 
sequences such as ^[[A (means Esc [ A). This is where that additional [ 
comes from. There is nothing wrong with that, except the TosWin2 bug found 
in the other thread. In application mode, it generates ^[OA that's also good.

4) Conflict between tw52 arrow codes and nano shortcuts
As said previously, M-A means Alt+A on modern terminals (not TosWin2). This 
is implemented in terminals by sending the Esc character followed by A. So 
this can also be manually simulated by pressing Esc then A. Not handy, but 
it works.

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.

When TERM is properly configured, the arrow keys have precedence and the 
shortcuts are unavailable. I believe this is correct.

5) tw100 terminfo
I don't see support for the ansi cuu1 ^[[A in the ncurses sources, in 
misc/terminfo.src. However, the demo_defkey test program displays the right 
thing KEY_UP, so that's fine. I believe there is some default somewhere. No 
trouble, here.
BTW, I seem that nano manually handles a lot of escape sequences by itself. 
See src/winio.c, function get_escape_seq_kbinput(). I'm not sure if this is 
used with ncurses, though.


As a conclusion, I propose to:

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

--
Vincent Rivière

#include <stdio.h>
#include <termios.h>

int main(void)
{
    struct termios term;

    tcgetattr(0, &term);
    term.c_lflag &= ~IEXTEN;
    tcsetattr(0, TCSANOW, &term);

    getchar();

    return 0;
}