From: nickrob@snap.net.nz (Nick Roberts)
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] GDB/MI documentation
Date: Thu, 14 May 2009 06:51:00 -0000 [thread overview]
Message-ID: <18955.48976.690330.445604@totara.tehura.co.nz> (raw)
In-Reply-To: <834ovoswt3.fsf@gnu.org>
> > Here are just a few basic changes that preserve the content.
>
> I'm okay with adding nodes, but the rest of the changes don't make the
> text any clearer than it is already.
I thought this change was so basic, obvious almost, that approval would be a
formality. Let's just look at two changes:
- Interaction of a @sc{GDB/MI} frontend with @value{GDBN} involves three
- parts---commands sent to @value{GDBN}, responses to those commands
- and notifications.
+ Interaction of a @sc{GDB/MI} frontend with @value{GDBN} involves three
+ parts: commands sent to @value{GDBN}; responses to those commands;
+ and notifications.
A wide dash (Em dash?) is normally used parenthetically while a semi-colon is
generally used for a list, often with a colon. The example at
http://en.wikipedia.org/wiki/Semicolon:
"She saw three men: Donald, who came from New Zealand; Jon, the milkman's son;
and George, a gaunt kind of man."
is almost identical to my change.
- Notifications is the mechanism for reporting changes in the state of the
- target,
+ Notifications are used for reporting changes in the state of the
+ target,
It's generally considered bad English to use "is" after a plural word.
If you think that correct punctuation and grammar don't make the text any
clearer then I'm a bit at a loss at what to say. Perhaps speling doesn't
matter either.
> > I think it would be quite easy to read GDB/MI General Design and still not
> > understand the overall purpose of GDB/MI.
>
> Feel free to suggest the text you think is missing. I'd welcome any
> such patches.
>
> TIA
Frankly, the overhead seems too high. I don't think it should be necessary
for every little change to have so many iterations. One step backward for
every four forward is better than taking no steps at all.
--
Nick http://www.inet.net.nz/~nickrob
next prev parent reply other threads:[~2009-05-14 6:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-13 10:36 Nick Roberts
2009-05-13 11:59 ` Vladimir Prus
2009-05-13 18:03 ` Eli Zaretskii
2009-05-13 18:05 ` Eli Zaretskii
2009-05-14 6:51 ` Nick Roberts [this message]
2009-05-14 15:22 ` Vladimir Prus
2009-05-14 22:07 ` Nick Roberts
2009-05-14 19:02 ` Eli Zaretskii
2009-05-14 21:50 ` Nick Roberts
2009-05-15 7:00 ` 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=18955.48976.690330.445604@totara.tehura.co.nz \
--to=nickrob@snap.net.nz \
--cc=eliz@gnu.org \
--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