From: Eli Zaretskii <eliz@gnu.org>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA/doco] document "set/show multiple-choice-auto-select"
Date: Fri, 25 Jan 2008 10:52:00 -0000 [thread overview]
Message-ID: <ulk6embqn.fsf@gnu.org> (raw)
In-Reply-To: <20080124213256.GA5796@adacore.com> (message from Joel Brobecker on Thu, 24 Jan 2008 13:32:56 -0800)
> Date: Thu, 24 Jan 2008 13:32:56 -0800
> From: Joel Brobecker <brobecker@adacore.com>
>
> I usually say that I'll send a doco update after a patch is accepted,
> but in this case, for once I'm sending the doco patch before I started
> working on the patch itself :).
Thanks!
> Right now, the documentation about menus is included as part of
> breakpoint support. I updated the documentation within that context
> for now. I'm not sure how to extend the documentation to cover
> the cases where breakpoints are not involved yet. One way of
> doing it would be to extract the current section out of the breakpoint
> documentation and make it more general. Another way would be to
> leave it as is, and then make another section somewhere else (somewhere
> inside "Examining Data/Program_Variables" that explains what happens
> when an ambiguous symbol name is used, with a reference to the
> Breakpoints Menu node.
>
> I think that the first option is a little bit better, but it's hard
> to tell.
I also think the first option is better. In fact, I did just that
recently for the description of ``locations'' in GDB, and didn't have
any major problems targeting the several commands that use them. In
the few cases where the difference mattered, I simply explained the
effect in each context.
A few comments about your patch:
> +By default when the location expression is ambiguous, @value{GDBN}
> +automatically selects all possible locations. But this behavior
> +can be configured so that a menu is of numbered choices for different
> +possible breakpoints is displayed (see below).
Something is wrong with the last sentence (two uses of ``is'' in
particular). What did you want to say?
> In that case, the @value{GDBN} waits
"the" should be removed here.
> +By default when the location expression is ambiguous, @value{GDBN}
> +automatically selects all possible locations. But this behavior
> +can be configured so that a menu is of numbered choices for different
> +possible breakpoints is displayed (see below).
I suggest to explicitly mention the name of the option here.
> +Typing @kbd{1} sets a breakpoint at each possible locations and typing
It's probably better to say
Typing @kbd{1 @key{RET}}
Since you need to type Enter after 1, right?
> +@item set multiple-choice-auto-select @var{mode}
> +@cindex menu auto select
> +This option allows you to adjust the debugger behavior when a location
> +expression is ambiguous. When set to @var{off}, the debugger does not
The last sentence should read
When @var{mode} is set to @code{off},
@var is only applicable to parameters whose names stand for some
specific value. "off" is such a specific value, so it's wrong to use
@var with it. Also, when you say "when set to off, the debugger ...",
it sounds like you are saying that the debugger is set to "off", which
is not what you want.
I also think that the default behavior should be described first, so
please make "all" the first value you describe, and please state right
away that it's the default (if that is so, see below):
When @var{mode} is set to @code{all} (the default), ...
> By default, this option is set to @var{all}.
Really? So your patch makes GDB behave differently by default than it
did before? I rather thought the default was "off", was I dreaming?
> +@item show multiple-choice-auto-select
> +Show the current value of the multiple-choice-auto-select setting.
The name of the option should be in @code.
prev parent reply other threads:[~2008-01-25 10:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-24 21:36 Joel Brobecker
2008-01-24 23:50 ` Nick Roberts
2008-01-25 2:56 ` Joel Brobecker
2008-01-25 4:24 ` Nick Roberts
2008-01-25 10:52 ` Eli Zaretskii [this message]
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=ulk6embqn.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/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