public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
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 --]

  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