PATCH: Use getche on Win32

PATCH: Use getche on Win32

[Mark Mitchell]

[This is the penultimate GDB-on-MinGW patch.]

Windows console semantics are different from UNIX.  If we just use
"read" to read what the user's typing, we end up blocking until a
newline is available, and even then there are some oddities.  The
easiest thing seems to be to use the special "getche" (short for "get
character with echo") routine which does the right thing.

Reviews?

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

2005-05-09  Mark Mitchell  <mark@codesourcery.com>

	* readline/input.c (rl_getc): Use getche to read console input on
	Windows.

Index: input.c
===================================================================
RCS file: /cvs/src/src/readline/input.c,v
retrieving revision 1.5
retrieving revision 1.5.60.1
diff -c -5 -p -r1.5 -r1.5.60.1
*** input.c	8 Dec 2002 22:31:37 -0000	1.5
--- input.c	5 Apr 2005 17:53:04 -0000	1.5.60.1
*************** rl_getc (stream)
*** 422,431 ****
--- 422,438 ----
    int result;
    unsigned char c;
  
    while (1)
      {
+ #ifdef __MINGW32__
+       /* On Windows, use a special routine to read a single character
+ 	 from the console.  (Otherwise, no characters are available
+ 	 until the user hits the return key.)  */
+       if (isatty (fileno (stream)))
+ 	  return getche ();
+ #endif
        result = read (fileno (stream), &c, sizeof (unsigned char));
  
        if (result == sizeof (unsigned char))
  	return (c);
  

Re: PATCH: Use getche on Win32

[Eli Zaretskii]

> Date: Mon, 9 May 2005 13:15:50 -0700
> From: Mark Mitchell <mark@codesourcery.com>
> Cc: gdb-patches@sources.redhat.com
> 
> Windows console semantics are different from UNIX.  If we just use
> "read" to read what the user's typing, we end up blocking until a
> newline is available, and even then there are some oddities.  The
> easiest thing seems to be to use the special "getche" (short for "get
> character with echo") routine which does the right thing.
> 
> Reviews?

What happens if you press one of the special keys, like Ctrl-C or the
arrow keys or PageDown?  Does getche still DTRT?

Re: PATCH: Use getche on Win32

[Mark Mitchell]

Eli Zaretskii wrote:
>>Date: Mon, 9 May 2005 13:15:50 -0700
>>From: Mark Mitchell <mark@codesourcery.com>
>>Cc: gdb-patches@sources.redhat.com
>>
>>Windows console semantics are different from UNIX.  If we just use
>>"read" to read what the user's typing, we end up blocking until a
>>newline is available, and even then there are some oddities.  The
>>easiest thing seems to be to use the special "getche" (short for "get
>>character with echo") routine which does the right thing.
>>
>>Reviews?
> 
> 
> What happens if you press one of the special keys, like Ctrl-C or the
> arrow keys or PageDown?  Does getche still DTRT?

Ctrl-C shows up as code 3, despite the fact that the documentation says 
that you can't read Ctrl-C.  The arrows and such are two-byte sequences; 
the first byte is 0xE0, while the second byte is a letter.  For example, 
left-arrow is 0xE0 0x50.  So, I'm not sure this entirely qualifies as 
"DTRT", but it's not totally broken either.

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

Re: PATCH: Use getche on Win32

[Eli Zaretskii]

> Date: Mon, 09 May 2005 23:00:41 -0700
> From: Mark Mitchell <mark@codesourcery.com>
> CC: bug-readline@gnu.org,  gdb-patches@sources.redhat.com
> 
> > What happens if you press one of the special keys, like Ctrl-C or the
> > arrow keys or PageDown?  Does getche still DTRT?
> 
> Ctrl-C shows up as code 3, despite the fact that the documentation says 
> that you can't read Ctrl-C.  The arrows and such are two-byte sequences; 
> the first byte is 0xE0, while the second byte is a letter.  For example, 
> left-arrow is 0xE0 0x50.

That's what I expected.

> So, I'm not sure this entirely qualifies as "DTRT"

"DTRT" in this case means raise SIGINT when Ctrl-C is pressed and go
left one character when left-arrow is pressed.

Re: PATCH: Use getche on Win32

[Mark Mitchell]

Eli Zaretskii wrote:
>>Date: Mon, 09 May 2005 23:00:41 -0700
>>From: Mark Mitchell <mark@codesourcery.com>
>>CC: bug-readline@gnu.org,  gdb-patches@sources.redhat.com
>>
>>
>>>What happens if you press one of the special keys, like Ctrl-C or the
>>>arrow keys or PageDown?  Does getche still DTRT?
>>
>>So, I'm not sure this entirely qualifies as "DTRT"
>
> "DTRT" in this case means raise SIGINT when Ctrl-C is pressed and go
> left one character when left-arrow is pressed.

I take it, then, that you are asking that I implement that functionality 
in readline?

I don't mind doing so; I was merely trying to make something useful 
available as soon as possible.

Thanks,

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

Re: PATCH: Use getche on Win32

[Eli Zaretskii]

> Date: Tue, 10 May 2005 13:04:52 -0700
> From: Mark Mitchell <mark@codesourcery.com>
> CC: bug-readline@gnu.org,  gdb-patches@sources.redhat.com
> 
> > "DTRT" in this case means raise SIGINT when Ctrl-C is pressed and go
> > left one character when left-arrow is pressed.
> 
> I take it, then, that you are asking that I implement that functionality 
> in readline?

Well, since we are talking about Readline for GDB, and given the
importance of SIGINT in GDB, I'd say at least Ctrl-C should work as
expected.  Editing keys are less critical, since one can always use
Ctrl-n, Ctrl-p, etc. (but it would be nice to have arrows, Home, End,
Delete, and Insert keys as well).

> I don't mind doing so; I was merely trying to make something useful 
> available as soon as possible.

If it's important that the current CVS snapshots are available ASAP
for MinGW users, even though one cannot interrupt the debuggee with
Ctrl-C, then I don't mind that you check this into the GDB CVS,
provided that it will be followed soon by more patches to take care of
the above issues.

Re: PATCH: Use getche on Win32

[Daniel Jacobowitz]

On Tue, May 10, 2005 at 11:22:17PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 10 May 2005 13:04:52 -0700
> > From: Mark Mitchell <mark@codesourcery.com>
> > CC: bug-readline@gnu.org,  gdb-patches@sources.redhat.com
> > 
> > > "DTRT" in this case means raise SIGINT when Ctrl-C is pressed and go
> > > left one character when left-arrow is pressed.
> > 
> > I take it, then, that you are asking that I implement that functionality 
> > in readline?
> 
> Well, since we are talking about Readline for GDB, and given the
> importance of SIGINT in GDB, I'd say at least Ctrl-C should work as
> expected.

That's a whole different problem; there's no way to read characters
that will cause proper SIGINT delivery, since the times when GDB cares
about SIGINT are the times when it is not in readline.  I don't know if
that's implementable at all (maybe Chris does?), but it won't be near
here.

Does Windows offer anything like appropriate job / pgrp semantics?
That'd really surprise me.

>  Editing keys are less critical, since one can always use
> Ctrl-n, Ctrl-p, etc. (but it would be nice to have arrows, Home, End,
> Delete, and Insert keys as well).
> 
> > I don't mind doing so; I was merely trying to make something useful 
> > available as soon as possible.
> 
> If it's important that the current CVS snapshots are available ASAP
> for MinGW users, even though one cannot interrupt the debuggee with
> Ctrl-C, then I don't mind that you check this into the GDB CVS,
> provided that it will be followed soon by more patches to take care of
> the above issues.

I would prefer not to commit patches now that will require followup
patches to change their behavior later; there's not that much of a rush
AFAIK.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: PATCH: Use getche on Win32

[Christopher Faylor]

On Tue, May 10, 2005 at 04:31:28PM -0400, Daniel Jacobowitz wrote:
>On Tue, May 10, 2005 at 11:22:17PM +0300, Eli Zaretskii wrote:
>> > Date: Tue, 10 May 2005 13:04:52 -0700
>> > From: Mark Mitchell <mark@codesourcery.com>
>> > CC: bug-readline@gnu.org,  gdb-patches@sources.redhat.com
>> > 
>> > > "DTRT" in this case means raise SIGINT when Ctrl-C is pressed and go
>> > > left one character when left-arrow is pressed.
>> > 
>> > I take it, then, that you are asking that I implement that functionality 
>> > in readline?
>> 
>> Well, since we are talking about Readline for GDB, and given the
>> importance of SIGINT in GDB, I'd say at least Ctrl-C should work as
>> expected.
>
>That's a whole different problem; there's no way to read characters
>that will cause proper SIGINT delivery, since the times when GDB cares
>about SIGINT are the times when it is not in readline.  I don't know if
>that's implementable at all (maybe Chris does?), but it won't be near
>here.
>
>Does Windows offer anything like appropriate job / pgrp semantics?
>That'd really surprise me.

Windows does support CTRL-C and does have process groups.  I don't know
how close the concept of a windows process group is to UNIX, though.

cgf

Re: PATCH: Use getche on Win32

[Christopher Faylor]

On Tue, May 10, 2005 at 05:38:21PM -0400, Christopher Faylor wrote:
>On Tue, May 10, 2005 at 04:31:28PM -0400, Daniel Jacobowitz wrote:
>>On Tue, May 10, 2005 at 11:22:17PM +0300, Eli Zaretskii wrote:
>>> > Date: Tue, 10 May 2005 13:04:52 -0700
>>> > From: Mark Mitchell <mark@codesourcery.com>
>>> > CC: bug-readline@gnu.org,  gdb-patches@sources.redhat.com
>>> > 
>>> > > "DTRT" in this case means raise SIGINT when Ctrl-C is pressed and go
>>> > > left one character when left-arrow is pressed.
>>> > 
>>> > I take it, then, that you are asking that I implement that functionality 
>>> > in readline?
>>> 
>>> Well, since we are talking about Readline for GDB, and given the
>>> importance of SIGINT in GDB, I'd say at least Ctrl-C should work as
>>> expected.
>>
>>That's a whole different problem; there's no way to read characters
>>that will cause proper SIGINT delivery, since the times when GDB cares
>>about SIGINT are the times when it is not in readline.  I don't know if
>>that's implementable at all (maybe Chris does?), but it won't be near
>>here.
>>
>>Does Windows offer anything like appropriate job / pgrp semantics?
>>That'd really surprise me.
>
>Windows does support CTRL-C and does have process groups.  I don't know
>how close the concept of a windows process group is to UNIX, though.

Btw, there are other alternatives to using getche.  You could just set
the correct mode using SetConsoleMode.

cgf

Re: PATCH: Use getche on Win32

[Eli Zaretskii]

> Date: Tue, 10 May 2005 17:42:18 -0400
> From: Christopher Faylor <me@cgf.cx>
> 
> >>Does Windows offer anything like appropriate job / pgrp semantics?
> >>That'd really surprise me.
> >
> >Windows does support CTRL-C and does have process groups.  I don't know
> >how close the concept of a windows process group is to UNIX, though.
> 
> Btw, there are other alternatives to using getche.  You could just set
> the correct mode using SetConsoleMode.

Right, and judging by what MSDN has to say about this, it's precisely
what Mark needs to get Readline do on Windows what it does on
platforms that support termios and similar Posix functionalities.

As for Ctrl-C, the same SetConsoleMode can evidently cause it to raise
SIGINT, as we want.

Re: PATCH: Use getche on Win32

[Mark Mitchell]

Eli Zaretskii wrote:
>>Date: Tue, 10 May 2005 17:42:18 -0400
>>From: Christopher Faylor <me@cgf.cx>
>>
>>>>Does Windows offer anything like appropriate job / pgrp semantics?
>>>>That'd really surprise me.
>>>
>>>Windows does support CTRL-C and does have process groups.  I don't know
>>>how close the concept of a windows process group is to UNIX, though.
>>
>>Btw, there are other alternatives to using getche.  You could just set
>>the correct mode using SetConsoleMode.
> 
> 
> Right, and judging by what MSDN has to say about this, it's precisely
> what Mark needs to get Readline do on Windows what it does on
> platforms that support termios and similar Posix functionalities.
> 
> As for Ctrl-C, the same SetConsoleMode can evidently cause it to raise
> SIGINT, as we want.

Strangely, I'd looked at that before, but not fully comprehended.  I'll 
experiment.  ENABLE_PROCESSED_INPUT may, however, cause certain 
characters (like the arrow keys) never to reach readline, thereby 
preventing some of the key-binding magic.  I'll try a few approaches, 
and report back.

Thanks,

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

MinGW build instructions (was: PATCH: Use getche on Win32)

[Eli Zaretskii]

As an aside, what little experience I have in porting Unix programs to
MinGW tells me that setting up an environment to build a package is
not a trivial job.  There are issues with what shell to use and how to
set it up, what ports of auxiliary tools (Coreutils, Grep, Awk, etc.)
to use and how to set them up, what non-default libraries to install
and link against (the MinGW libraries such as libiberty, Libgw32c), etc.

So perhaps, if we are going to have an alive MinGW port, it is a good
idea to have a README.MinGW file in the distro that would describe how
to build such a port of GDB.  A description of the setup Mark uses to
work on the port would be a good starting point.

You can use the file gdb/config/djgpp/README as an example of solving
a similar problem, although the nature of the details is different, of
course.

TIA

Re: MinGW build instructions

[Mark Mitchell]

Eli Zaretskii wrote:
> As an aside, what little experience I have in porting Unix programs to
> MinGW tells me that setting up an environment to build a package is
> not a trivial job.  There are issues with what shell to use and how to
> set it up, what ports of auxiliary tools (Coreutils, Grep, Awk, etc.)
> to use and how to set them up, what non-default libraries to install
> and link against (the MinGW libraries such as libiberty, Libgw32c), etc.
> 
> So perhaps, if we are going to have an alive MinGW port, it is a good
> idea to have a README.MinGW file in the distro that would describe how
> to build such a port of GDB.  A description of the setup Mark uses to
> work on the port would be a good starting point.

I'd be happy to write it up -- but what I do is simple: I cheat.  I use 
cross compilers from i686-pc-linux-gnu to i686-ming32.  If it would be 
useful for me to show how I configure and build GDB like that, I'm happy 
to write that up; just let me know.

Thanks,

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

Re: MinGW build instructions

[Eli Zaretskii]

> Date: Wed, 11 May 2005 00:21:16 -0700
> From: Mark Mitchell <mark@codesourcery.com>
> CC: gdb-patches@sources.redhat.com
> 
> I'd be happy to write it up -- but what I do is simple: I cheat.  I use 
> cross compilers from i686-pc-linux-gnu to i686-ming32.  If it would be 
> useful for me to show how I configure and build GDB like that, I'm happy 
> to write that up; just let me know.

I think it will be better than nothing, and the information about the
non-default libraries you link in should be good for other builds as
well.

With luck, other people who build GDB for Windows will report their
setups as well, so with time more possible setups will be in the file.

Re: MinGW build instructions

[Christopher Faylor]

On Wed, May 11, 2005 at 12:21:16AM -0700, Mark Mitchell wrote:
>Eli Zaretskii wrote:
>>As an aside, what little experience I have in porting Unix programs to
>>MinGW tells me that setting up an environment to build a package is
>>not a trivial job.  There are issues with what shell to use and how to
>>set it up, what ports of auxiliary tools (Coreutils, Grep, Awk, etc.)
>>to use and how to set them up, what non-default libraries to install
>>and link against (the MinGW libraries such as libiberty, Libgw32c), etc.
>>
>>So perhaps, if we are going to have an alive MinGW port, it is a good
>>idea to have a README.MinGW file in the distro that would describe how
>>to build such a port of GDB.  A description of the setup Mark uses to
>>work on the port would be a good starting point.
>
>I'd be happy to write it up -- but what I do is simple: I cheat.  I use 
>cross compilers from i686-pc-linux-gnu to i686-ming32.  If it would be 
>useful for me to show how I configure and build GDB like that, I'm happy 
>to write that up; just let me know.

Some people use the cygwin-fork (grr...) MSYS to do mingw development.
It should contain every package that you need to build gdb, I think.
And, I am mentioning this through gritted teeth in the interests of
full disclosure.

At least one of the mingw developers just uses cygwin to do mingw
development, which, of course, seems to be to be the ultimate solution
if you want to work on windows.  AFAIK, cygwin's libraries like autoconf
and gettext seem to be updated more frequently than MSYS.

You don't have to install 700MB of cygwin to get things working.  You
should be able to get away with just installing the bits that you need +
the mingw compiler.  Or, it is possible that a i686-pc-mingw32-gcc
wrapper like:

#!/bin/sh
exec gcc -mno-cygwin "$@"

may "just work" with the cygwin version of gcc.  The -mno-cygwin option
to gcc actually uses the mingw headers and libraries.  Unfortunately,
there is a problem with cygwin-bleedover for libraries, though, so
you have to be careful not to specify any libraries on the command
line which exist on cygwin but not in mingw.  This is something that
I keep meaning to fix in gcc/binutils...

cgf

Re: MinGW build instructions

[Eli Zaretskii]

> Date: Wed, 11 May 2005 12:11:53 -0400
> From: Christopher Faylor <me@cgf.cx>
> 
> You don't have to install 700MB of cygwin to get things working.  You
> should be able to get away with just installing the bits that you need +
> the mingw compiler.  Or, it is possible that a i686-pc-mingw32-gcc
> wrapper like:
> 
> #!/bin/sh
> exec gcc -mno-cygwin "$@"
> 
> may "just work" with the cygwin version of gcc.  The -mno-cygwin option
> to gcc actually uses the mingw headers and libraries.  Unfortunately,
> there is a problem with cygwin-bleedover for libraries, though, so
> you have to be careful not to specify any libraries on the command
> line which exist on cygwin but not in mingw.  This is something that
> I keep meaning to fix in gcc/binutils...

Thanks for the info.

However, what is needed are precise instructions based on actual
experience.  If I were someone who needs for the first time compile a
GNU package on Windows, it would not help me to know that
such-and-such setup ``might just work''.  The subtleties of running
various ports of GNU tools on Windows are not something a newbie
should need to learn as part of their first job.  If someone knows
exactly how to set up a build environment where the MinGW port of GDB
can be built, please describe that.  In particular, what parts of
Cygwin need to be installed and how to run the compiler.

Also, the configuration that you suggest: some part of Cygwin and the
MinGW compiler, will probably suffer from incompatibilities due to
Cygwin file names that the MinGW compiler probably doesn't understand,
symlinks that the utilities such as ln support, but the MinGW compiler
might not, etc.  I didn't try MSYS, but it sounds that they did
resolve these problems in a more satisfactory manner.  So I don't
really understand why you don't like their alternative.  Is it known
to have some serious problems?

Re: MinGW build instructions

[Christopher Faylor]

On Wed, May 11, 2005 at 09:41:35PM +0300, Eli Zaretskii wrote:
>> Date: Wed, 11 May 2005 12:11:53 -0400
>> From: Christopher Faylor
>> 
>> You don't have to install 700MB of cygwin to get things working.  You
>> should be able to get away with just installing the bits that you need +
>> the mingw compiler.  Or, it is possible that a i686-pc-mingw32-gcc
>> wrapper like:
>> 
>> #!/bin/sh
>> exec gcc -mno-cygwin "$@"
>> 
>> may "just work" with the cygwin version of gcc.  The -mno-cygwin option
>> to gcc actually uses the mingw headers and libraries.  Unfortunately,
>> there is a problem with cygwin-bleedover for libraries, though, so
>> you have to be careful not to specify any libraries on the command
>> line which exist on cygwin but not in mingw.  This is something that
>> I keep meaning to fix in gcc/binutils...
>
>Thanks for the info.
>
>However, what is needed are precise instructions based on actual
>experience.  If I were someone who needs for the first time compile a
>GNU package on Windows, it would not help me to know that
>such-and-such setup ``might just work''.

Yes, I know that, Eli.  These were hints for someone who might want to
try it.  They were not intended as step-by-step instructions since,
obviously I can't provide those.  I thought that maybe they'd be
useful for someone who was interested in trying this.

>Also, the configuration that you suggest: some part of Cygwin and the
>MinGW compiler, will probably suffer from incompatibilities due to
>Cygwin file names that the MinGW compiler probably doesn't understand,
>symlinks that the utilities such as ln support, but the MinGW compiler
>might not, etc.

I don't see why.  You just install the mingw compiler and put it in your
path.  There obviously won't be any cygwin symlinks in the mingw compiler
tar ball.

>I didn't try MSYS, but it sounds that they did resolve these problems
>in a more satisfactory manner.

I doubt it.  MSYS's claim to fame is that you don't have to use the
cygwin mount table.  AFAIK, it does nothing special with symlinks.  Msys
would not have problems with cygwin bleed over I mentioned since
there wouldn't be any cygwin components.

OTOH, as I mentioned, AFAIK all of MSYS's components lag cygwin in terms
of bug fixes and frequency of updates.

It's odd that you apparently don't like my not being specific enough but
then go on to postulate general problems with things that you haven't
tried.  But, regardless, I was just offering opinions.  It seems like my
offering information has now gotten me into YA debate.  I think I'm
learning some kind of lesson here.

>So I don't really understand why you don't like their alternative.  Is
>it known to have some serious problems?

How much would you like someone saying "I've got this new version of
tools that I've called CFGPP" if the tools were a repackaging of DJGPP
with some patches?  What if the person involved in CFGPP was
occasionally apparently fixing bugs but not pushing them back to DJGPP?
How about if the CFGPP web site made no mention of the fact that it was
95% DJGPP with some changes?  How about if CFGPP binaries started
showing up which played badly with DJGPP and people started asking you
to fix DJGPP so that it worked better with CFGPP?  How about if people
started asking CFGPP questions in the DJGPP mailing lists?

These are standard problems with a fork and my reaction, as the project
lead for Cygwin, is a typical reaction to a fork.  I don't know if MSYS
has serious problems.  I haven't heard of any but I'm not going to
endorse it because I use another alternative.

cgf

Re: MinGW build instructions

[Eli Zaretskii]

> Date: Wed, 11 May 2005 15:15:50 -0400
> From: Christopher Faylor <me@cgf.cx>
> 
> >Also, the configuration that you suggest: some part of Cygwin and the
> >MinGW compiler, will probably suffer from incompatibilities due to
> >Cygwin file names that the MinGW compiler probably doesn't understand,
> >symlinks that the utilities such as ln support, but the MinGW compiler
> >might not, etc.
> 
> I don't see why.

Because the configure script runs the compiler to probe the system.
If configure creates symlinks, the compiler might fail because it
doesn't support them.  Also, in some packages, the script creates
symlinks which the compiler then needs to access during the build,
like in the case of nm-* files in GDB.

> It's odd that you apparently don't like my not being specific enough but
> then go on to postulate general problems with things that you haven't
> tried.

I didn't postulate them, I just suggested that perhaps there might be
a problem.

FWIW, in my few attempts to build GNU packages with MinGW I found that
a Unixy shell is the only missing part, as long as you don't need to
run Automake, Autoconf, etc.  After some looking around, I used the
MinGW ports of the standard utilities and a Windows port of zsh that I
found on the net.  It worked quite well, but that was a simple
package, nowhere near the complexities of GDB, with its multilevel
subdirectories.

> >So I don't really understand why you don't like their alternative.  Is
> >it known to have some serious problems?
> 
> How much would you like someone saying "I've got this new version of
> tools that I've called CFGPP" if the tools were a repackaging of DJGPP
> with some patches?

Ah, okay.  I thought there were some technical problems.  Thanks for
the info.

Re: PATCH: Use getche on Win32

[Mark Mitchell]

Daniel Jacobowitz wrote:

>>If it's important that the current CVS snapshots are available ASAP
>>for MinGW users, even though one cannot interrupt the debuggee with
>>Ctrl-C, then I don't mind that you check this into the GDB CVS,
>>provided that it will be followed soon by more patches to take care of
>>the above issues.

Thanks!  But ...

> I would prefer not to commit patches now that will require followup
> patches to change their behavior later; there's not that much of a rush
> AFAIK.

... I agree that there's no burning crisis, and I don't want to do 
something that makes people unhappy.

As Daniel says, the Ctrl-C issue is independent of this code, and, as 
Chris says, it's perfectly possible to capture Ctrl-C under Windows; we 
just don't want to do it here.

What I can do in this context is look at Home/End/Delete/Insert/Arrows. 
  I'll do that and report back.

Thanks,

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

Re: PATCH: Use getche on Win32

[Eli Zaretskii]

> Date: Tue, 10 May 2005 23:54:46 -0700
> From: Mark Mitchell <mark@codesourcery.com>
> CC: Eli Zaretskii <eliz@gnu.org>,  bug-readline@gnu.org, 
>  gdb-patches@sources.redhat.com
> 
> As Daniel says, the Ctrl-C issue is independent of this code, and, as 
> Chris says, it's perfectly possible to capture Ctrl-C under Windows; we 
> just don't want to do it here.

In the last sentence, what does ``here'' mean?  Do you mean you don't
want to do it in Readline?  If so, I think it's a mistake: the Unix
code of Readline clearly does manipulate signals, and I think a
Windows port should be as close to it as it can.

Re: PATCH: Use getche on Win32

[Mark Mitchell]

Eli Zaretskii wrote:
>>Date: Tue, 10 May 2005 23:54:46 -0700
>>From: Mark Mitchell <mark@codesourcery.com>
>>CC: Eli Zaretskii <eliz@gnu.org>,  bug-readline@gnu.org, 
>> gdb-patches@sources.redhat.com
>>
>>As Daniel says, the Ctrl-C issue is independent of this code, and, as 
>>Chris says, it's perfectly possible to capture Ctrl-C under Windows; we 
>>just don't want to do it here.
> 
> 
> In the last sentence, what does ``here'' mean?  Do you mean you don't
> want to do it in Readline?  If so, I think it's a mistake: the Unix
> code of Readline clearly does manipulate signals, and I think a
> Windows port should be as close to it as it can.

You are of course correct that readline manipulates signals.  In 
particular, it registers signal handlers at the start of the function 
named readline, and then removes them before returning.  It would indeed 
be desirable that the Windows version behave as much like POSIX as 
possible in this respect.

However, when you said earlier that handling Ctrl-C was very important 
to GDB, Daniel and I understood you to be referring to the ability to 
interrupt the inferior when readline is not active.  In other words, 
after you say "run", you may want to hit Ctrl-C before you reach a 
breakpoint.  That functionality is independent of readline; it comes 
from signal handlers that GDB itself installs.

So, what I wrote is way too strong a statement.  I should have just said 
that handling Ctrl-C here is not as critical as elsewhere.  I also can't 
find any suggestion that readline actually reads the "Ctrl" and "C" 
characters through its main input loop; instead, I think that it just 
installs signal handlers in the usual way.  It's possible that I've just 
not find the right bit yet, though.

Thanks,

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

Re: PATCH: Use getche on Win32

[Eli Zaretskii]

> Date: Thu, 12 May 2005 23:29:26 -0700
> From: Mark Mitchell <mark@codesourcery.com>
> CC: drow@false.org,  bug-readline@gnu.org, 
>  gdb-patches@sources.redhat.com
> 
> However, when you said earlier that handling Ctrl-C was very important 
> to GDB, Daniel and I understood you to be referring to the ability to 
> interrupt the inferior when readline is not active.  In other words, 
> after you say "run", you may want to hit Ctrl-C before you reach a 
> breakpoint.  That functionality is independent of readline; it comes 
> from signal handlers that GDB itself installs.

True.  But please note that setting the terminal in Readline so that
it reads individual characters and gets SIGINT when you press is
imperative to make sure SIGINT is delivered to GDB, even when you are
not inside Readline code.  So these two issues are not completely
independent; in particular, once you find a way to get SIGINT into
Readline, you will have found a way to get SIGINT into GDB's signal
handlers as well.

> So, what I wrote is way too strong a statement.  I should have just said 
> that handling Ctrl-C here is not as critical as elsewhere.

Agreed.

> I also can't find any suggestion that readline actually reads the
> "Ctrl" and "C" characters through its main input loop; instead, I
> think that it just installs signal handlers in the usual way.  It's
> possible that I've just not find the right bit yet, though.

If you mean on Posix platforms, then yes: Ctrl-C never gets to the
program, because the signal-generation machinery acts on it first.

If you mean Windows, do you mean to say that the signal handler is
installed, but never invoked?  I'm not sure I understand what is that
``right bit'' that you are looking for.

Re: PATCH: Use getche on Win32

[Eli Zaretskii]

> Date: Tue, 10 May 2005 16:31:28 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Mark Mitchell <mark@codesourcery.com>, bug-readline@gnu.org,
> 	gdb-patches@sources.redhat.com
> 
> > Well, since we are talking about Readline for GDB, and given the
> > importance of SIGINT in GDB, I'd say at least Ctrl-C should work as
> > expected.
> 
> That's a whole different problem; there's no way to read characters
> that will cause proper SIGINT delivery, since the times when GDB cares
> about SIGINT are the times when it is not in readline.

Is that really so?  What about a completion attempt that went haywire,
or a too long output to the screen?

> > > I don't mind doing so; I was merely trying to make something useful 
> > > available as soon as possible.
> > 
> > If it's important that the current CVS snapshots are available ASAP
> > for MinGW users, even though one cannot interrupt the debuggee with
> > Ctrl-C, then I don't mind that you check this into the GDB CVS,
> > provided that it will be followed soon by more patches to take care of
> > the above issues.
> 
> I would prefer not to commit patches now that will require followup
> patches

Me neither.  But Mark seemed to be saying that he wanted usable GDB as
soon as possible, see above.