public inbox for util-linux@vger.kernel.org
 help / color / mirror / Atom feed
From: Benno Schulenberg <bensberg@justemail.net>
To: kerolasa@gmail.com
Cc: "Util-Linux" <util-linux@vger.kernel.org>
Subject: Re: [PATCH 1/4] setterm: add usage() descriptions
Date: Sun, 25 May 2014 22:51:21 +0200	[thread overview]
Message-ID: <1401051081.24456.121397993.69EFB4EB@webmail.messagingengine.com> (raw)
In-Reply-To: <CAG27Bk2bgpkodp2FgxmXkUhoSe8rWAuBFh40bU6t+1rmavHg2g@mail.gmail.com>


On Sun, May 25, 2014, at 12:57, Sami Kerola wrote:
> Ah, I see. It would be really good to get an example of literate
> argument to both howtos.
> 
> Documentation/howto-man-page.txt
> Documentation/howto-usage-function.txt
> 
> Maybe something like this
> 
> diff --git a/Documentation/howto-man-page.txt b/Documentation/howto-man-page.txt
> [...]
>  .TP
> +\fB\-l\fR, \fB\-\-literal\fR \fIword\fR
> +Tell in description option argument is required and that it can be only
> +.BR word .

Well, yes, but it should be \fBword\fR. -- bold.

> + -L, --literal [arg|foo] required argument is one of the literal strings

Yes, but better not use the word "arg" because it sounds too much
like it has to be replaced with something.  Better: "--literal [foo|baz]".

> >> +     fputs(_(" --foreground    <default|color>   set foreground color\n"), out);
> >
> > default|<color>
> 
> Colors are literal strings so [color], and that can be short cut to
> [default|color] where color possibilities are explained in later line.

...  No!  Yes, colors are literal strings, but not the word color itself,
that's why it's written as <color>.  ...  Okay, let's say this differently:
--foreground is an option, it can take nine or ten different arguments.
One of the possible arguments is the literal word "default", and all
the other ones are names for colors, but not the word "color" itself,
of course -- so it is written as "default|<color>".  And the argument
of --foreground is not optional, so no square brackets.


> >> +     fputs(_(" --regtabs       <1-160>           set default tab stop position\n"), out);
> >
> > To be consistent this should be "--regtabs <number>", and then add that
> > <number> can be 1..160.  But that loses conciseness.
> 
> Options --tab argument <number> defines length of a specific tab,
> while the --regtabs is a range. In former the number is value, and in
> later more like literal string, constant, or a definition.

??  ...  I think you have the two mixed up.  The option --tabs takes a sequence
of numbers as arguments, so it should be "<number>..." (it probably should be
an ascending sequence, but the man page doesn't say).  The option --regtabs
takes a single number as argument, so "<number>" -- 'regtabs' seems to be
short for "regular tabs" or "tabs at a regular interval", and the number gives
the size of the interval.  All these numbers are constant values.

> >> +     fputs(_(" --blank         <0-60|force|poke> set inactivity interval\n"), out);
> >
> > --blank  [<number>|force|poke]
> > and <number> can be 1..60 (minutes)
> 
> Same here. This dualistic 'number as value' and 'number as definition'

I don't understand what you mean with this dualistic nature.

> may need an example to howtos files. IMHO the long description in
> which range is '<number>' and later text tells '<number> has range 1
> to 60' is too verbose, good usage() is brief, man page as verbose as
> needed.

Yes, I agree that using <number> and then explaining what <number> can be
is somewhat verbose, so it is okay to use "--blank  [0-60|force|poke]",
like the man page does.

Benno

-- 
http://www.fastmail.fm - Send your email first class


  reply	other threads:[~2014-05-25 20:51 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-24 11:08 [PATCH 0/4] setterm: documentation updates Sami Kerola
2014-05-24 11:08 ` [PATCH 1/4] setterm: add usage() descriptions Sami Kerola
2014-05-24 12:30   ` Benno Schulenberg
2014-05-25 10:57     ` Sami Kerola
2014-05-25 20:51       ` Benno Schulenberg [this message]
2014-05-24 11:08 ` [PATCH 2/4] docs: setterm.1 add missing options to manual page and remove duplicate Sami Kerola
2014-05-24 12:33   ` Benno Schulenberg
2014-05-25 10:57     ` Sami Kerola
2014-05-24 11:08 ` [PATCH 3/4] docs: setterm.1 add options compatibility note Sami Kerola
2014-05-24 12:38   ` Benno Schulenberg
2014-05-25 10:58     ` Sami Kerola
2014-05-24 11:08 ` [PATCH 4/4] docs: setterm.1 clean up manual page groff style Sami Kerola
2014-05-24 12:44   ` Benno Schulenberg
2014-05-25 10:58     ` Sami Kerola
2014-05-25 21:10       ` Benno Schulenberg
2014-05-26  8:42         ` Sami Kerola
2014-05-26 10:11           ` Karel Zak
2014-05-26 15:46             ` Sami Kerola
2014-05-27 14:46               ` Karel Zak
2014-05-29  9:48                 ` Sami Kerola
2014-05-29 10:23                   ` Ruediger Meier
2014-05-30  7:44                     ` Sami Kerola
2014-06-01 22:35                       ` Ruediger Meier
2014-06-02 16:42                         ` Sami Kerola
2014-06-02 21:23                           ` Bernhard Voelker
2014-06-02 21:35                             ` Ruediger Meier

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=1401051081.24456.121397993.69EFB4EB@webmail.messagingengine.com \
    --to=bensberg@justemail.net \
    --cc=kerolasa@gmail.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