All of lore.kernel.org
 help / color / mirror / Atom feed
From: J William Piggott <elseifthen@gmx.com>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org
Subject: Re: [PATCH 04/12] hwclock: add usage() functions heading
Date: Tue, 20 Jun 2017 20:59:20 -0400	[thread overview]
Message-ID: <9f28d294-f05c-2f98-ccc0-bc968c062416@gmx.com> (raw)
In-Reply-To: <20170620083649.qunrwp7dsxcaspot@ws.net.home>



On 06/20/2017 04:36 AM, Karel Zak wrote:
> On Sun, Jun 18, 2017 at 08:41:45PM -0400, J William Piggott wrote:
>> -#define USAGE_MAN_TAIL(_man)   _("\nFor more details see %s.\n"), _man
>> +#define USAGE_MAN_TAIL(_man)   _("\nFor more details see %s\n"), _man
> 
> What's wrong with the period?

_I put it back_, but here is my opinion why it shouldn't be there:

* the rest of usage() doesn't use line-ending periods

* the super class grammar rule is 'be consistent'

* usage() is a vertical list so line-ending periods are not required

* the \n at the beginning and end of this string means it is standalone
   sentence (vertical list) so a line-ending period is not required.

* the main purpose (perhaps the only purpose) of a line-ending period is
  to improve readability in paragraphs of text. That is, when one
  sentence ends and another begins in the middle of a line.

* a passage of text with mixed use of line-ending punctuation for
  sentences degrades readability. Long term readers are conditioned to
  recognize properly delimited text and will parse it with less
  scrutiny; only to find out part way through that the burden of
  separating sentences is (sometimes) on them.

* it just looks wrong to have a screen full of usage() text without a
  period in sight, only to have one show up at EOF.

Pretty much the same reasons that I advocate that message strings should
not use periods. They are vertical lists and do not require it; we have
some message strings that cannot have line-ending periods, so to follow
the 'be consistent' grammar rule, none of them should. An added benefit
would be that simple rules are easy document, easy to remember, and easy
to enforce. Easier than: with warn() don't use. Otherwise use. Except if
it is not a sentence. Well, maybe use it on fragments that the author
intended to be a complete sentence ... a simple 'don't use them' is much
easier, yes? What to do if a message string has two sentences on one
line? Put them on separate lines, otherwise rewrite them as a single
sentence.


> 
>     Karel
> 

  reply	other threads:[~2017-06-21  0:59 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-19  0:35 [PATCH 00/12] pull request J William Piggott
2017-06-19  0:37 ` [PATCH 01/12] hwclock: remove dead code in usage() J William Piggott
2017-06-19  0:38 ` [PATCH 02/12] hwclock: update usage() to util-linux style J William Piggott
2017-06-19  0:40 ` [PATCH 03/12] hwclock: update usage() FILE name J William Piggott
2017-06-19  0:41 ` [PATCH 04/12] hwclock: add usage() functions heading J William Piggott
2017-06-20  8:36   ` Karel Zak
2017-06-21  0:59     ` J William Piggott [this message]
2017-06-21 12:21   ` Ruediger Meier
2017-06-21 15:59     ` J William Piggott
2017-06-19  0:42 ` [PATCH 05/12] include: update pathnames.h J William Piggott
2017-06-20  8:44   ` Karel Zak
2017-06-21  0:53     ` J William Piggott
2017-06-19  0:44 ` [PATCH 06/12] hwclock: use RTC in help output J William Piggott
2017-06-19  0:45 ` [PATCH 07/12] hwclock: update --help content and grammar J William Piggott
2017-06-20  8:51   ` Karel Zak
2017-06-21  0:53     ` J William Piggott
2017-06-21 13:05     ` Ruediger Meier
2017-06-21 14:55       ` Karel Zak
2017-06-21 15:30         ` J William Piggott
2017-06-22  2:04           ` Ruediger Meier
2017-06-22 18:46             ` J William Piggott
2017-06-21 15:01     ` Karel Zak
2017-06-21 17:02       ` J William Piggott
2017-06-19  0:46 ` [PATCH 08/12] hwclock: slice up the usage text J William Piggott
2017-06-19  0:47 ` [PATCH 09/12] hwclock: add --update-drift check J William Piggott
2017-06-19  0:48 ` [PATCH 10/12] Docs: update howto-usage-function.txt J William Piggott
2017-06-19  0:49 ` [PATCH 11/12] hwclock: remove unused usage() FILE argument J William Piggott
2017-06-20  8:56   ` Karel Zak
2017-06-21  0:52     ` J William Piggott
2017-06-28 19:29     ` fputs() vs puts() (was: [PATCH] hwclock: remove unused usage() FILE argument) Ruediger Meier
2017-06-29  8:51       ` Karel Zak
2017-06-29 10:37         ` Ruediger Meier
2017-06-29 10:53           ` Karel Zak
2017-06-29 14:46             ` fputs() vs puts() J William Piggott
2017-06-29 20:12               ` Karel Zak
2017-06-30 18:29                 ` J William Piggott
2017-07-03  8:30                   ` Ruediger Meier
2017-07-03 12:07                     ` Karel Zak
2017-07-03 12:38                       ` Ruediger Meier
2017-07-03 14:25                         ` Karel Zak
2017-07-03 15:09                           ` Bernhard Voelker
2017-07-03 15:15                             ` Bernhard Voelker
2017-06-29 10:37         ` fputs() vs puts() (was: [PATCH] hwclock: remove unused usage() FILE argument) Karel Zak
2017-06-21  9:26   ` [PATCH 11/12] hwclock: remove unused usage() FILE argument Karel Zak
2017-06-21 15:48     ` J William Piggott
2017-06-25 21:39       ` J William Piggott
2017-06-19  0:51 ` [PATCH 12/12] hwclock: remove unused stdarg.h J William Piggott
2017-06-21  9:27 ` [PATCH 00/12] pull request Karel Zak

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=9f28d294-f05c-2f98-ccc0-bc968c062416@gmx.com \
    --to=elseifthen@gmx.com \
    --cc=kzak@redhat.com \
    --cc=util-linux@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.