Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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