Util-Linux package development
 help / color / mirror / Atom feed
From: "Benno Schulenberg" <bensberg@justemail.net>
To: kerolasa@gmail.com
Cc: "Karel Zak" <kzak@redhat.com>, "util-linux" <util-linux@vger.kernel.org>
Subject: Re: man-pages and usage() howto
Date: Sat, 20 Aug 2011 11:10:05 +0200	[thread overview]
Message-ID: <1313831405.14363.140258131741205@webmail.messagingengine.com> (raw)
In-Reply-To: <CAG27Bk3Kvzy+cLCaGh885XLo-MsYY3i5q6_380b_DE8KxXmaNA@mail.gmail.com>

On Wed, 17 Aug 2011 15:07 +0200, "Sami Kerola" <kerolasa@iki.fi> wrote:
> On Tue, Aug 16, 2011 at 12:39, Karel Zak <kzak@redhat.com> wrote:
> >
> >    --date <time>
> >
> >  the important is visual difference between static option name
> >  and variable option argument.
> 
> Diamond brackets make visual difference to look quite nice. I do
> like this.

Yes, it does look better than all uppercase, so I'll accept.
(That I stuck to uppercase is because it wastes less space,
and with just 80 characters width this sometimes matters,
plus it seemed widespread tradition.)

>  -n, --no-argument     this option requires no_argument
>  -o, --optional[=arg]  this option has optional_argument
>  -r, --required <arg>  this option requires required_argument

The middle one would need the pointy brackets, too, no?

 -o, --optional[=<arg>]  this option has optional_argument

> >  I'm just working on Benno's patches and I found that we need
> >  some explicitly defined rules for usage():
> >
> >    - "Usage:" and "Options:" use separate lines and strings, before
> >       the sections has to be empty line:
> >
> >       fputs(_("\nUsage:\n"), out);
> >       ...
> >       fputs(_("\nOptions:\n"), out);
> >
> >     (so this two string will be translated only once)

As a translator I do not quite like the separation of the 
"\nUsage:\n" string from the actual synopsis -- it is good
to have some context in the string.  But I'll accept.  The
initial space of the actual synopsis strings will eventually
let translators understand what they are.

> How putting to c.h the following?
> 
> #define USAGE_HEADER _("\nUsage:\n")
> #define USAGE_OPTIONS _("\nOptions:\n")
> #define USAGE_SHORT_TAIL _("\n")
> #define USAGE_MAN_TAIL _("For more details see %s.")

Especially the latter would be nice: at the moment there are
many such lines with just a differing final word.

> Having also definition for OPTION_HELP && OPTION_VERSION would be
> good.

That won't work -- the amount of indentation for the option description
is not the same for all utilities.  And to make it the same for all would
create ugly and unneeded wide open text spaces for some tools.


> >  I made the decision, --option <argument>.  [...]
> >
> >  It would be also nice to sync man pages with usage() format.

Do you mean that you want to use "--option <argument>" also in the
man pages, Karel?  Or do we stick there to italics for arguments?
(Which translates to underlining on terminals.)

Regards,

Benno

-- 
http://www.fastmail.fm - Email service worth paying for. Try it for free

  reply	other threads:[~2011-08-20  9:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-15 14:19 man-pages and usage() howto Karel Zak
2011-08-15 19:12 ` Sami Kerola
2011-08-16  9:03   ` Benno Schulenberg
2011-08-16 10:46     ` Karel Zak
2011-08-17 13:07       ` Sami Kerola
2011-08-20  9:10         ` Benno Schulenberg [this message]
2011-08-20 19:08           ` Sami Kerola
2011-08-21 10:56             ` Sami Kerola
2011-08-22  8:16             ` Karel Zak
2011-08-22 18:53               ` Sami Kerola
2011-08-22 20:38             ` Benno Schulenberg
2011-08-23  8:15               ` Sami Kerola
2011-08-23 18:55                 ` Benno Schulenberg
2011-08-23 19:34                   ` Sami Kerola
2011-08-16 10:39   ` 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=1313831405.14363.140258131741205@webmail.messagingengine.com \
    --to=bensberg@justemail.net \
    --cc=kerolasa@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox