From: Paul Hilfinger <hilfingr@gnat.com>
To: eliz@gnu.org
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA]: Turn on Ada support
Date: Wed, 09 Jun 2004 09:23:00 -0000 [thread overview]
Message-ID: <20040609092355.AA07EF2956@nile.gnat.com> (raw)
In-Reply-To: <3405-Wed09Jun2004011206+0300-eliz@gnu.org>
Eli,
Thanks for your comments. I have adopted most of them. Comments on your
comments follow.
> I don't mind, provided that those placebos never see a GDB release: I
> don't want to have a manual released with empty sections/nodes. So if
> you plan to finish them up before the next release, it's okay in the
> meantime to have them in the form you left them.
In that case, I think I'll just remove these stubs. They're easy enough
to insert when implemented.
> > +in function or file @var{B}.'' When @var{B} is a file name, you must typically
> > +surround it in single quotes.
>
> What else can B be in this context?
A function name. I take it "function or file @var{B}" is too terse for you?
> > +@table @code
> > +@item break exception
>
> Every user command should be indexed with a @kindex. (In this case,
> it's sufficient to have a single "@kindex break exception" rather
> than 2 entries, as these are variations of the same command.)
Actually, we'll remove this, because it isn't yet implemented and its syntax
going to be changed anyway.
> This should say "as of @value{GDBN} version X.YY". A year or two from
> now, someone will have hard time updating this verbiage given the
> changes in Ada support.
OK, but I am not sure what editorial comment you are implying with the
word "verbiage" (:->).
> > +The type of the @t{'Address} attribute may not be @t{System.Address}.
>
> I think you should use @code instead of @t in this and similar cases.
Umph. The problem is that @code{'Address} generates `'Address' in Info files,
which looks odd.
Paul
next prev parent reply other threads:[~2004-06-09 9:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-08 9:08 Paul Hilfinger
2004-06-08 22:15 ` Eli Zaretskii
2004-06-09 9:23 ` Paul Hilfinger [this message]
2004-06-09 18:25 ` Eli Zaretskii
2004-06-10 9:40 ` Paul Hilfinger
2004-06-09 7:24 ` Jim Blandy
2004-06-09 9:40 ` Paul Hilfinger
2004-06-09 13:12 ` Daniel Jacobowitz
2004-06-09 13:40 ` Andrew Cagney
2004-06-09 16:21 ` Jim Blandy
2004-06-10 9:50 ` Paul Hilfinger
2004-06-16 8:42 ` [RFA]: Turn on Ada support, take 2 Paul Hilfinger
2004-06-16 18:07 ` Eli Zaretskii
2004-06-17 5:24 ` Paul Hilfinger
2004-06-17 17:48 ` Eli Zaretskii
2004-06-16 8:34 ` [PATCH]: Further updates to ada-* files Paul Hilfinger
2004-06-27 0:10 ` Andrew Cagney
2004-06-27 8:56 ` Paul Hilfinger
2004-06-28 14:47 ` Andrew Cagney
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=20040609092355.AA07EF2956@nile.gnat.com \
--to=hilfingr@gnat.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sources.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