From: Elena Zannoni <ezannoni@redhat.com>
To: tromey@redhat.com
Cc: Elena Zannoni <ezannoni@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: Patch: RFA: operate-and-get-next fix
Date: Wed, 24 Jul 2002 10:29:00 -0000 [thread overview]
Message-ID: <15678.57929.895918.500305@localhost.redhat.com> (raw)
In-Reply-To: <87it35ukud.fsf@fleche.redhat.com>
Tom Tromey writes:
> >>>>> "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.
>
Ah, ok.
> 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.
>
Hey, just cut-n-paste what you wrote above. Seems pretty clear to me.
>
> 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.
>
I should look to see if the new readline has improved a bit in this sense.
you can commit the changes, however, the testsuite change....is Fernando's.
thanks
Elena
> Tom
next prev parent reply other threads:[~2002-07-24 17:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-23 18:37 Tom Tromey
2002-06-19 10:58 ` Elena Zannoni
2002-06-19 12:19 ` Tom Tromey
2002-07-23 20:02 ` Tom Tromey
2002-07-24 9:50 ` Elena Zannoni
2002-07-24 10:23 ` Tom Tromey
2002-07-24 10:29 ` Elena Zannoni [this message]
2002-07-24 10:55 ` Tom Tromey
2002-07-24 11:01 ` Elena Zannoni
2002-07-24 11:02 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15678.57929.895918.500305@localhost.redhat.com \
--to=ezannoni@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox