From: Ruediger Meier <sweet_f_a@gmx.de>
To: Bernhard Voelker <mail@bernhard-voelker.de>
Cc: Karel Zak <kzak@redhat.com>,
J William Piggott <elseifthen@gmx.com>,
util-linux@vger.kernel.org
Subject: Re: [PATCH 3/5] hwclock: final usage() strings slice
Date: Tue, 4 Jul 2017 10:55:05 +0200 [thread overview]
Message-ID: <201707041055.05661.sweet_f_a@gmx.de> (raw)
In-Reply-To: <192a27a9-6e22-5483-0222-23cd992af8d2@bernhard-voelker.de>
On Tuesday 04 July 2017, Bernhard Voelker wrote:
> On 07/04/2017 09:58 AM, Karel Zak wrote:
> > I think the idea is to use the extra space only if you mix printf
> > and puts in the same code block. We have on many place only puts
> > (or fputs) -- in this case the extra space is unnecessary.
>
> What about putting the strings on an extra line regardless whether
> that is output via printf or fputf or ...; e.g.
> http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/du.c#n278
> ?
Yes this is nice because easy to count that no usage output is longer
than 80 chars. But I guess there are too many different opinions about
these stylish things. I'd also like to have just one string and only
one printf command for all options (like mkfs.cramfs.c). But this may
cause more work for translators each time we add a new option. Don't
know if that would be a real problem.
cu,
Rudi
next prev parent reply other threads:[~2017-07-04 8:55 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-02 19:45 [PATCH 0/5] pull request J William Piggott
2017-07-02 19:50 ` [PATCH 1/5] hwclock: remove from usage() FILE *out = stdout J William Piggott
2017-07-02 19:51 ` [PATCH 2/5] hwclock: usage() use program_invocation_short_name J William Piggott
2017-07-03 8:46 ` Ruediger Meier
2017-07-03 15:14 ` J William Piggott
2017-07-03 19:31 ` J William Piggott
2017-07-02 19:53 ` [PATCH 3/5] hwclock: final usage() strings slice J William Piggott
2017-07-03 8:51 ` Ruediger Meier
2017-07-03 15:35 ` J William Piggott
2017-07-04 7:58 ` Karel Zak
2017-07-04 8:34 ` Bernhard Voelker
2017-07-04 8:55 ` Ruediger Meier [this message]
2017-07-04 9:00 ` Bernhard Voelker
2017-07-04 16:53 ` Karel Zak
2017-07-04 17:06 ` Karel Zak
2017-07-05 17:45 ` J William Piggott
2017-07-02 19:54 ` [PATCH 4/5] docs: update boilerplate.c usage() J William Piggott
2017-07-02 19:55 ` [PATCH 5/5] hwclock: sync one-liner descriptions J William Piggott
2017-07-10 23:34 ` [PING - REBASED][PATCH 0/5] pull request J William Piggott
2017-07-11 8:06 ` Karel Zak
2017-07-11 17:54 ` J William Piggott
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=201707041055.05661.sweet_f_a@gmx.de \
--to=sweet_f_a@gmx.de \
--cc=elseifthen@gmx.com \
--cc=kzak@redhat.com \
--cc=mail@bernhard-voelker.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox