From: JWP <elseifthen@gmx.com>
To: Benno Schulenberg <bensberg@justemail.net>
Cc: Util-Linux <util-linux@vger.kernel.org>, karel Zak <kzak@redhat.com>
Subject: Re: [PATCH 2/4] docs: mention that setarch may not be able to set all listed architectures
Date: Sun, 11 Jan 2015 13:43:21 -0500 [thread overview]
Message-ID: <54B2C449.8010206@gmx.com> (raw)
In-Reply-To: <1420996041.3944497.212461717.015CE843@webmail.messagingengine.com>
On 01/11/2015 12:07 PM, Benno Schulenberg wrote:
>
> On Sun, Jan 11, 2015, at 17:19, JWP wrote:
>> On 01/10/2015 08:41 AM, Benno Schulenberg wrote:
>>> -\fB\-\-uname\-2.6\fR
>>> -Causes the program to see a kernel version number beginning with 2.6.
>>> +.B \-\-uname-2.6
>>
>> This is incorrect. Options are always constructed with minus signs never a hyphens.
>> The only time a hyphen should be used in man-pages is for normally hyphenated
>> dictionary words. Commands, options, variables, paths, urls, etc. all use the
>> minus sign character.
>
> You are right. However, on a terminal both hyphen and minus sign render
> to 0x2d. When printed, the characters are rendered differently, and then
> I prefer to see a tiny hyphen instead of a minus sign in hyphenated options.
> And since you cannot copy and paste from a printed document, it doesn't
> matter that the more readable hyphen is used instead of the correct minus
> sign.
The world is going paperless, favoring print manuals over online is going the
wrong direction. Just because it uses the same glyph on your terminal does not
mean the same will be true for every application that renders a man-page.
However, the more important point is not what glyph is printed, but how troff
formats a hyphen vs a minus sign. We do not want line breaks made mid: command,
command string, option, variable, url, etc. It could be argued that when
they are located near the left margin, such as in TP context, it would not
cause formatting issues, but they need to be kept consistent through out the
document and are often later used mid-paragraph.
If one of them is split with a hyphen at line end, how does one know if the
hyphen was added for formatting, or if it is part of the name?
I ran into that exact problem with persistent_clock_is_local in the hwclock
man-page. That is why I added the \% you asked about.
>
> See also 'git log -p --author=bjarniig' and search for "to '-'", and also
> http://www.spinics.net/lists/util-linux-ng/msg09260.html near the end.
Change '\-' (minus) to '-' (code "hyphen-minus", rendered with the
glyph 'hyphen' in troff), if it is a part of a compound word.
Yes, I said that compound words are the only place to use the hyphen. Dictionary
compound words. Most options do not form legitimate compound words, and even if
they did you should not hyphenate them. They need to be presented as they are used,
on paper or otherwise.
Then later in commit 2ad6d4f Mr. Gislason says:
Change '-' to '\-', if it indicates an option
Change '--' to '\-\-', if it indicates an option
I hope he did not then make a minus in the 'word' of the option a hyphen.
>
> If you maintain that the correct \- should be used, there will be a
> large patch to make.
>
> Benno
>
next prev parent reply other threads:[~2015-01-11 18:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-10 13:41 [PATCH 1/4] setarch: differentiate between "unrecognized" and "cannot set" Benno Schulenberg
2015-01-10 13:41 ` [PATCH 2/4] docs: mention that setarch may not be able to set all listed architectures Benno Schulenberg
2015-01-11 16:19 ` JWP
2015-01-11 17:07 ` Benno Schulenberg
2015-01-11 18:43 ` JWP [this message]
2015-01-12 10:41 ` karel Zak
2015-01-12 11:23 ` Karel Zak
2015-01-10 13:41 ` [PATCH 3/4] setarch: accept the option --list in any position Benno Schulenberg
2015-01-12 11:25 ` Karel Zak
2015-01-10 13:41 ` [PATCH 4/4] setarch: in the usage text only mention options that actually do something Benno Schulenberg
2015-01-12 11:33 ` Karel Zak
2015-01-12 11:23 ` [PATCH 1/4] setarch: differentiate between "unrecognized" and "cannot set" 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=54B2C449.8010206@gmx.com \
--to=elseifthen@gmx.com \
--cc=bensberg@justemail.net \
--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.