public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: linux-man@vger.kernel.org
Subject: preferred /proc/<pid>/xxx style?
Date: Fri, 9 Dec 2022 18:41:05 +0900	[thread overview]
Message-ID: <Y5MCsc/H9BV6RcST@vapier> (raw)

[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]

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.  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.

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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

             reply	other threads:[~2022-12-09  9:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-09  9:41 Mike Frysinger [this message]
2022-12-09 19:43 ` preferred /proc/<pid>/xxx style? Alejandro Colomar
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=Y5MCsc/H9BV6RcST@vapier \
    --to=vapier@gentoo.org \
    --cc=linux-man@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