From: Joel Brobecker <brobecker@adacore.com>
To: Markus Deuling <deuling@de.ibm.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
gdb-patches@sourceware.org, Ulrich Weigand <uweigand@de.ibm.com>
Subject: Re: [RFA] new set/show multiple-choice-auto-select commands
Date: Tue, 15 Jan 2008 12:37:00 -0000 [thread overview]
Message-ID: <20080115123700.GK9143@adacore.com> (raw)
In-Reply-To: <478C7C48.2010502@de.ibm.com>
Hi Markus,
> I attached a patch which introduces a new command "set symbol-user-choice
> on" which is off per default. If set to on a symbol lookup finding
> >1 appropriate symbol (for example break foo, with foo in main and in a
> >shared lib) a user choice (decode_line_2) is invoked.
The principle is indeed the same. The semantics of your command
are a little unclear to me, as you didn't say what should happen
if symbol-user-choice is off and you have more than one symbol matching.
Do you cancel the lookup, choose all symbols, and pick one at random?
We have one non-technical issue to solve if we are to merge the two
ideas into one setting: You suggest the default to be off, which means
no menu. But in Ada, we want the default to be "on" because we have
always printed these menus in Ada, and removing them now would be
a change of behavior.
> Maybe we can merge the patches? I'd like to see the "set
> symbol-user-choice on|off" command rather in a language-undependent
> place like linespec.c as in a language-specific file like ada. What do
> you think? Do you see the possibility for that?
Absolutely. The reason why I posted this patch as a RFC is that
I realized that this feature could be used for all languages,
not just Ada. It's still on my plate to adjust the patch to put
this in linespec instead of ada-lang - I will get to it soon.
Would you be ok with using my command, however? I like the name better,
but most of all, it's a little more complete: It's a tri-state setting
as opposed to a binary one. We need to resolve the issue of the default.
> Btw, I'd really appreciate your feedback on that patch. Would this be ok
> for mainline?
I'll admit that I only quickly scanned the patch, because I actually
prefer the command that I suggested...
--
Joel
next prev parent reply other threads:[~2008-01-15 12:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-01 14:36 Joel Brobecker
2008-01-01 20:16 ` Eli Zaretskii
2008-01-02 4:35 ` Joel Brobecker
2008-01-05 11:03 ` Eli Zaretskii
2008-01-15 9:29 ` Markus Deuling
2008-01-15 12:37 ` Joel Brobecker [this message]
2008-01-16 7:32 ` Markus Deuling
2008-01-16 10:20 ` Joel Brobecker
2008-01-16 10:40 ` Markus Deuling
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=20080115123700.GK9143@adacore.com \
--to=brobecker@adacore.com \
--cc=deuling@de.ibm.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=uweigand@de.ibm.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