From: Alejandro Colomar <alx.manpages@gmail.com>
To: Mike Frysinger <vapier@gentoo.org>, linux-man@vger.kernel.org
Cc: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Subject: Re: preferred /proc/<pid>/xxx style?
Date: Fri, 9 Dec 2022 20:43:21 +0100 [thread overview]
Message-ID: <bc30d5ac-c33b-9a67-fa85-1003da0057f5@gmail.com> (raw)
In-Reply-To: <Y5MCsc/H9BV6RcST@vapier>
[-- Attachment #1.1: Type: text/plain, Size: 3949 bytes --]
Hi Mike!
On 12/9/22 10:41, Mike Frysinger wrote:
> while browsing time_namespaces(7), i noticed it's inconsistent when it comes to
> styling of /proc/<pid>/paths. it uses the styles:
> * .IR /proc/ pid /ns/time_for_children
> * .I /proc/PID/timens_offsets
>
> grepping the tree turns up more:
> * .I /proc/<pid>/maps
> * .I /proc/[pid]/status
>
> it seems that the tree is moving towards the first style.
That's correct.
> personally i find
> that jarring to read because it's using italics for the whole path except for
> the pid which has no styling at all. in the terminal this yields colored &
> underlined text except for the "pid" which is just plain text like the rest.
>
> commit 1ae6b2c7b818e5d8804cf8d3abfdb6fba32119db made a large change recently
> to proc(5) to use .IR, but with no explanation in the commit message other
> than to satisfy a linter, and running that linter locally doesn't seem to show
> any warnings when using the previous /proc/[pid] style.
You probably don't get the linter warnings because I think that requires
groff-1.23.0 (still unreleased; hopefully available soon).
We're talking about the following diff:
-.IR /proc/[pid]/fdinfo
+.IR /proc/ pid /fdinfo
Using '.IR' with a single argument results in a warning, since it would be
better written as '.I'. However, I decided to apply the style fix instead of
simplfy fixing the warning. I should have been more detailed in the commit
message. I only covered it with "Plus some other found in the process.".
>
> the man-pages(7) guidance doesn't covert this afaict. it has:
>> Formatting conventions (general)
>> Filenames (whether pathnames, or references to header files) are always in italics ...
> that implies it should be only in italics.
It isn't covered in man-pages(7), AFAIK. However, it is covered by
groff_man_style(7) (also unreleased; maybe your version of groff_man(7) covers it):
groff_man_style(7):
.I [text]
...
Use italics for file and path names, for environment variables,
for C data types, for enumeration or preprocessor constants in
C, for variable (user‐determined) portions of syntax synopses,
for the first occurrence (only) of a technical concept being in‐
troduced, for names of journals and of literary works longer
than an article, and anywhere a parameter requiring replacement
by the user is encountered. *An exception* involves variable text
in a context that is already marked up in italics, such as file
or path names with variable components; in such cases, follow
the convention of mathematical typography: set the file or path
name in italics as usual but use roman for the variable part
(see .IR and .RI below), and italics again in running roman text
when referring to the variable material.
I marked the start of the important part.
I will some day make it consistent across all pages.
Cheers,
Alex
>
> if we look a bit further, using .IR seems inconsistent.
>> SYNOPSIS
>> For commands, this shows the syntax of the command and its arguments (including options);
>> boldface is used for as-is text and italics are used to indicate replaceable arguments
>>
>> Formatting conventions for manual pages describing commands
>> For manual pages that describe a command (...), the arguments are always specified using italics
>>
>> Formatting conventions for manual pages describing functions
>> For manual pages that describe functions (...), the arguments are always specified using italics,
>> even in the SYNOPSIS section, where the rest of the function is specified in bold:
> -mike
P.S.: Please CC me :)
--
<http://www.alejandro-colomar.es/>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-12-09 19:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-09 9:41 preferred /proc/<pid>/xxx style? Mike Frysinger
2022-12-09 19:43 ` Alejandro Colomar [this message]
2022-12-09 21:03 ` G. Branden Robinson
2022-12-09 21:09 ` words (and commands) that I learnt because of Branden (was: preferred /proc/<pid>/xxx style?) Alejandro Colomar
2022-12-09 22:10 ` Deri
[not found] ` <CAGcdajfWk+=xR3UfAnNri0F7OL0mFJ4xsp=sQoWLo_-_G5wcBA@mail.gmail.com>
2022-12-10 7:15 ` hbezemer
2022-12-10 8:57 ` G. Branden Robinson
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=bc30d5ac-c33b-9a67-fa85-1003da0057f5@gmail.com \
--to=alx.manpages@gmail.com \
--cc=g.branden.robinson@gmail.com \
--cc=linux-man@vger.kernel.org \
--cc=vapier@gentoo.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