From: Eli Zaretskii <eliz@gnu.org>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [obv] add kindex for set remote hardware-{watchpoint,breakpoint}-limit
Date: Mon, 06 Aug 2012 16:19:00 -0000 [thread overview]
Message-ID: <83obmo9eoi.fsf@gnu.org> (raw)
In-Reply-To: <1981863.INEZdKZT0P@qiyao.dyndns.org>
> From: Yao Qi <yao@codesourcery.com>
> Date: Mon, 6 Aug 2012 23:29:13 +0800
>
> On Friday, August 03, 2012 06:09:59 PM Eli Zaretskii wrote:
> > Sorry, but it isn't obvious. You will see that this whole node has
> > only one kindex entry: "@kindex set remote". There are other "set
> > remote SOMETHING" commands described there, but none of them has a
> > @kindex entry.
> >
> > The reason for that is simple: it is not useful to have several index
> > entries that all begin with the same string and all point to the same
> > page.
>
> The reason I post this patch is that I was unable to find 'set remote
> hardware-breakpoint-limit' in 'Command and Variable Index'.
But "set remote" is there, isn't it?
When you cannot find a subcommand in the index, you should go for its
parent command.
> I thought we need
> kindex for *every* command in documentation, and that is why we need "index".
> Otherwise, the criteria of using kindex is not clear, IMO.
The criteria for kindex is to index every command, but not necessarily
every subcommand. So "set remote" is indexed.
Another example of a command with lots of subcommands which are not
indexed is "set print" (although I see that a couple of subcommands
sneaked in).
Again, having lots of index entries with identical beginning pointing
to the same page is not useful. Think how this looks in the printed
manual, for example.
OK?
next prev parent reply other threads:[~2012-08-06 16:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-03 15:00 Yao Qi
2012-08-03 15:10 ` Eli Zaretskii
2012-08-06 15:29 ` Yao Qi
2012-08-06 16:19 ` Eli Zaretskii [this message]
2012-08-07 1:10 ` Yao Qi
2012-08-07 2:52 ` 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=83obmo9eoi.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=yao@codesourcery.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