All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Štěpán Němec" <stepnem@gmail.com>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: linux-man@vger.kernel.org,
	Alejandro Colomar <alx.manpages@gmail.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: [PATCH 4/6] xattr.7: wfix
Date: Sat, 30 Jul 2022 16:15:21 +0200	[thread overview]
Message-ID: <20220730161521+0200.203910-stepnem@gmail.com> (raw)
In-Reply-To: <20220729205823.lcy4fbezlw32owgu@illithid>


Hello Branden,

On Fri, 29 Jul 2022 15:58:23 -0500
G. Branden Robinson wrote:

>> -The VFS imposes limitations that an attribute names is limited to 255 bytes
>> -and an attribute value is limited to 64\ kB.
>> +The VFS-imposed limits on attribute names and values are 255 bytes
>> +and 64\ kB, respectively.
>
> While you're tidying this up, I would convert the `\ ` escape sequence
> to `\~`.  Both are non-breaking spaces, but the latter is adjustable.
>
> groff_man(7) from groff 1.22.4 says:
>
>  \~     Adjustable, non-breaking space character.  Use  this  escape  to
>         prevent  a  break  inside  a short phrase or between a numerical
>         quantity and its corresponding unit(s).
>
>                Before starting the motor, set the output speed to\~1.
>                There are 1,024\~bytes in 1\~kiB.
>                CSTR\~#8 documents the B language.

Thank you for the review!

I think I disagree: IMO a number+unit should be treated as a single
entity both semantically/logically and typographically (at least as far
as space stretching goes), i.e., say (if I understand the effect of '\ '
and '\~' right),

  255 bytes               and                64 kB,          respectively.

would make a bit more sense to me than

  255        bytes        and         64         kB,         respectively.

Current Linux man-pages usage doesn't appear quite consistent, but '\ '
prevails over '\~' (about 6:1), and my cursory grep found only one
instance of '\~' used between a number and its unit (vs. many instances
of '\ ' in that context).

In view of the above, failing any instruction from a man-pages
maintainer to the contrary, I'd prefer leaving this as is.

  With best wishes,

  Štěpán

  reply	other threads:[~2022-07-30 14:14 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-29 11:45 [PATCH 4/6] xattr.7: wfix Štěpán Němec
2022-07-29 20:58 ` G. Branden Robinson
2022-07-30 14:15   ` Štěpán Němec [this message]
2022-07-30 17:53     ` Alejandro Colomar (man-pages)
2022-07-30 17:59       ` Alejandro Colomar (man-pages)
2022-08-01 13:28       ` Alejandro Colomar
2022-08-11 12:48         ` Ingo Schwarze
2022-08-11 20:17           ` G. Branden Robinson
2022-08-12 14:30             ` Ingo Schwarze
2022-08-12 22:10               ` *roff `\~` support (was: [PATCH 4/6] xattr.7: wfix) G. Branden Robinson
2022-08-13  4:23                 ` G. Branden Robinson
2022-08-14 14:15                   ` Ingo Schwarze
2022-08-14 22:21                     ` G. Branden Robinson
2022-08-13 17:27                 ` DJ Chase
2022-08-14 13:56                   ` Standardize roff (was: *roff `\~` support) Ingo Schwarze
2022-08-14 14:49                     ` DJ Chase
2022-08-14 16:32                       ` Alejandro Colomar
2022-08-14 19:43                         ` DJ Chase
2022-08-15 11:59                           ` Alejandro Colomar
2022-08-16 11:48                             ` Ingo Schwarze
2022-08-14 22:35                       ` G. Branden Robinson
2022-08-14 22:58                         ` DJ Chase
2022-08-15  0:20                     ` Sam Varshavchik
2022-08-16 12:52                       ` Standardize roff Ingo Schwarze
2022-08-16 23:46                         ` Sam Varshavchik

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=20220730161521+0200.203910-stepnem@gmail.com \
    --to=stepnem@gmail.com \
    --cc=alx.manpages@gmail.com \
    --cc=g.branden.robinson@gmail.com \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    /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.