Re: Patch: RFA: operate-and-get-next fix

[Tom Tromey <tromey@redhat.com>]

>>>>> "Elena" == Elena Zannoni <ezannoni@redhat.com> writes:

>> +/* This is like readline(), but it has some gdb-specific behavior.  In
>> +   particular, if the user is in the middle of an
>> +   operate-and-get-next, we shuffle the hooks around so that the
>> +   expected result occurs.  This is ugly, but it is inevitable given
>> +   that gdb switches between the two modes (async and not) of using
>> +   readline and that rl_pre_input_hook doesn't work properly in async
>> +   mode.  */

Elena> Ok for the other changes, but I don't understand why you are
Elena> setting rl_pre_input_hook in the async case, while in top.c
Elena> there is a comment saying the opposite:

The thing is, gdb uses both readline in both the synchronous and async
modes during a single invocation.

At the ordinary top-level prompt we might be using the async
readline.  That means we can't use rl_pre_input_hook, since it doesn't
work properly in async mode.

However, for a secondary prompt (" >", such as occurs during a
`define'), gdb just calls readline() directly, running it in
synchronous mode.

So for operate-and-get-next to work in this situation, we have to
switch the hooks around.  That is what gdb_readline_wrapper is for.

I thought the comment quoted above explained the situation.
Apparently, though, it didn't.  Can you suggest how I should change it
to be more clear?  I'll make the changes and resubmit the patch.


Long term the best fix here, in my opinion, is to fix readline so that
rl_pre_input_hook works properly in all situations.  That code is
pretty convoluted, though.  When I looked at it (must have been a year
ago now) it didn't look fun.

Tom