Re: PATCH: Readline for MinGW

[Mark Mitchell <mark@codesourcery.com>]

Mark Kettenis wrote:

> Huh?  AFAIK, POSIX doesn't say anything about arrow keys or the
> sequences produced by it.  That's all determined by the terminal type.

Yes.  Good point.

> Hmm, it looks like that readline simply hardcodes the ANSI sequences
> for these keys instead of consulting termcap.  Not your fault though.
> But if it did consult termcap, you could provide a stub tgetent() that
> did the mapping.

Indeed.

> Incidentally, I find the way you find you write the macros a bit
> confusing:
> 
>    + #ifdef __MINGW32__
>    +    /* Under Windows, when an extend key (like an arrow key) is
>    +       pressed, getch() will return 0xE0 followed by a code for the
>    +       extended key.  We use macros to transform those into the normal
>    +       UNIX sequences for these keys.  */
>    + 
>    +    /* Up arrow.  */
>    +    rl_macro_bind ("\340H", "\033[A", map);
>    +    /* Left arrow.  */
>    +    rl_macro_bind ("\340K", "\033[D", map);
>    +    /* Right arrow.  */
>    +    rl_macro_bind ("\340M", "\033[C", map);
>    +    /* Down arrow.  */
>    +    rl_macro_bind ("\340P", "\033[B", map);
>    + #endif
> 
> It has "\34" and "\033" on the same line so I get confused whether
> "\34" is octal or not...
> 
> Also, I don't see any trace of the 0xE0 you mention in the comment.

You're right; that's a suboptimal comment.  Both "\340" and "\033" are 
octal constants; "\033" is 0x27, or escape, and "\340" is 0xe0, which is 
the Windows way of providing an escape sequence.  I have updated my copy 
of the comment to:

   .... return 340 (octal) followed by a ...

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304