This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: PATCH: Readline for MinGW
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: mark at codesourcery dot com
- Cc: gdb-patches at sources dot redhat dot com, bug-readline at gnu dot org
- Date: Sun, 12 Jun 2005 09:31:22 +0200 (CEST)
- Subject: Re: PATCH: Readline for MinGW
- References: <200506081742.j58Hg6O0017392@sethra.codesourcery.com>
Date: Wed, 8 Jun 2005 10:42:06 -0700
From: Mark Mitchell <mark@codesourcery.com>
The problems solved by this patch are:
1. Windows does not have termcap/curses/etc. So, we provide a stub
files that contains basic implementations of the relevant
functions. That permits the remainder of the code to continue
using the POSIX interfaces unchanged.
2. The arrow keys use different extended key sequences on Windows than
on POSIX systems; we introduce readline macros to transform the
Windows sequences into their POSIX equivalents. This approach
again confines the Windows-isms to a single point.
Huh? AFAIK, POSIX doesn't say anything about arrow keys or the
sequences produced by it. That's all determined by the terminal type.
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.
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.
Mark