From: Daniel Jacobowitz <drow@false.org>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] Patch to limit field name completion candidates
Date: Thu, 05 Jun 2008 19:46:00 -0000 [thread overview]
Message-ID: <20080605194553.GG25085@caradoc.them.org> (raw)
In-Reply-To: <m3k5h3d6xt.fsf@fleche.redhat.com>
On Thu, Jun 05, 2008 at 01:21:02PM -0600, Tom Tromey wrote:
> Daniel> I am concerned that relying on the parser to parse incomplete
> Daniel> expressions will not work out. The bodies won't be run until the rule
> Daniel> is reduced, and there may not be enough context in what the user has
> Daniel> typed to reduce the field completion. I'm not sure that's a real
> Daniel> problem, but I worry that it will be fragile. Still - clearly better
> Daniel> than nothing.
>
> I thought about this too, but I couldn't think of a failing case.
>
> We aren't parsing complete expressions, true, but I think by the time
> the COMPLETE token is reduced, we will have reduced the entire LHS of
> the struct op expression. And, we throw away the rest of the
> expression -- all the malformed parts.
>
> So, I think it ought to be safe in all cases.
Safe, yes. That's not the failure mode I was worried about. I'm
wondering if we will ever error out before we reduce the COMPLETE.
But it seems to work so far.
> Daniel> Oh, and at least a NEWS entry would be good - and probably a
> Daniel> manual change too.
>
> I added a NEWS entry. I am not sure where in the manual to add
> anything though. FWIW I didn't do this originally since it seems more
> like a QoI thing than a feature requiring documentation.
Yes, I understand - but at the same time, the more of our QoI we crow
about, the more users will take advantage of it, and the cooler
they'll think GDB is. If it was worth implementing, it's also worth
documenting.
Another example near the bottom of Command Completion would probably
do it.
The patch and test are OK! Work out the NEWS and manual bits with
Eli, and you're home free.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2008-06-05 19:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-13 17:01 Tom Tromey
2008-05-13 18:11 ` Eli Zaretskii
2008-05-13 18:20 ` Tom Tromey
2008-05-13 18:32 ` Daniel Jacobowitz
2008-05-13 18:36 ` Tom Tromey
2008-05-13 21:00 ` Eli Zaretskii
2008-05-13 20:52 ` Eli Zaretskii
2008-06-05 17:10 ` Daniel Jacobowitz
2008-06-05 19:21 ` Tom Tromey
2008-06-05 19:30 ` Eli Zaretskii
2008-06-05 20:02 ` Tom Tromey
2008-06-06 9:47 ` Eli Zaretskii
2008-06-05 19:46 ` Daniel Jacobowitz [this message]
2008-06-05 20:03 ` Tom Tromey
2008-06-05 20:08 ` Daniel Jacobowitz
2008-06-06 0:49 ` Tom Tromey
2008-06-06 2:32 ` Daniel Jacobowitz
2008-06-06 2:41 ` Tom Tromey
2008-06-06 10:28 ` Eli Zaretskii
2008-06-06 17:50 ` Tom Tromey
2008-06-06 19:46 ` Eli Zaretskii
2008-06-06 19:54 ` Daniel Jacobowitz
2008-06-05 20:50 ` Tom Tromey
2008-06-06 10:13 ` Eli Zaretskii
2008-06-06 10:53 ` Eli Zaretskii
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=20080605194553.GG25085@caradoc.them.org \
--to=drow@false.org \
--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