All of lore.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 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.