prompt in console window

[Nicholas_Karagas@cirilium.com]

>>
>> Hello, Insight gurus...
>>
>> I've recently come across a problem using the console window in Insight.
>> In ordinary GDB, if the number of lines printed exceeds the 'height'
>> parameter, then the debugger will issue the prompt '---Type <return> to
>> continue, or q <return> to quit---'.  However, this apparently doesn't
work
>> in the Insight console, as the call to readline (readline.c:337) from
>> prompt_for_continue (utils.c:1619) always returns 0x0, and never shows
the
>> prompt in the console window.  I imagine that this is because readline
>> expects everything to be going to and from stdout (since it doesn't
require
>> a stream as a parameter).  Is there a quick fix for this that doesn't
>> involve fiddling with readline, and therefore binutils (I think that's
>> where it lives)?  Thanks in advance.
>
>Ugh. Don't even ask. This is very nasty, and not particularly useful in
>a GUI, anyway (IMO). That's why man invented scrollbars. O:-)
>
>The trick that Insight uses to turn this off is "set height 0", which
>tells gdb that the window height is zero lines high. This can be
>overridden by setting it to some number, but I just tried it in a recent
>snapshot, and it did exactly what I thought it would: it works as
>expected, but the message "---Type <return>..." appears in the
>controlling terminal, not in the console window. (Which reminds me, why
>haven't we closed stdout???) This happens because this message is passed
>to readline to handle, and readline doesn't understand how to use the
>GUI's printing streams. In order for anything to show up in the GUI, all
>output MUST pass through fputs_unfiltered, which is hooked. This
>function is called by all of gdb's printf_unfiltered/filtered commands.
>(So if anyone happens to see a "printf" or "fprintf" or "putc" or "puts"
>or anything like them without "_unfiltered" or "_filtered" in gdb, it's
>a bug.)
>
>We could hack readline to take an input/output hook, but when we
>upgraded to the lastest version of readline, we really wanted to avoid
>any hacking. I suspect this could be done, but I've not taken a good,
>serious look at readline.
>
>Of course, the console window could be modified to do this, too. It
>probably wouldn't be too difficult, either, but it would not qualify as
>"quick". Use ConsoleWin::insert to count the number of lines inserted,
>when it hits some maximum, output the prompt, wait for the keypress,
>etc. The trick, though, is that many internal messages/errors are sent
>to the console. One must be certain that we are processing user input
>when we do this (so set some flag saying it's okay to do this in
>ConsoleWin::invoke). That part would be quick, but hooking it all up to
>the preferences dialog and all the little nitpicks (adding online
>documentation for it) can be too easily overlooked.
>
>Keith
>--
>Why chat when you can Firetalk?
>Firetalk ID: Keith (10320)
>www.firetalk.com

Hmm... perhaps I can ask an easier question.  The only reason that I wanted
to get the prompt_for_continue prompt back was that I wanted a way to stop
a gdb macro (the kind that are defined in the .gdbinit file) that had
started running, in case it was taking too long and I didn't care about the
rest of the output.  With the command-line gdb, you could type Ctrl-C at
that prompt to stop whatever was running, including a macro.  Would it be
easier (and more helpful to the rest of the world) to get Ctrl-C working in
the console window instead of the unnecessary prompt?

Nicholas Karagas
Associate Software Engineer
Cirilium Corporation
Tempe, AZ
(480) 317-1144