All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: mtk.manpages@gmail.com, linux-man <linux-man@vger.kernel.org>
Subject: Re: man-pages.7: Simplify indentation of structure definitions, shell session logs, and so on
Date: Tue, 29 Sep 2020 15:12:05 +0200	[thread overview]
Message-ID: <f4180fa9-2154-53ee-b29b-580d4d1dc662@gmail.com> (raw)
In-Reply-To: <20200927060319.lhyctckcnk6mtuas@localhost.localdomain>

On 9/27/20 8:03 AM, G. Branden Robinson wrote:
> At 2020-09-24T10:15:31+0200, Michael Kerrisk (man-pages) wrote:
>> On 9/21/20 4:15 PM, G. Branden Robinson wrote:
> [much snippage]
>>> In my opinion, .in requests are never necessary in idiomatic,
>>> well-written man pages and I'm happy to offer technical advice for
>>> how to achieve the desired result without using them.
>>
>> So, I don't disagree with you. (And as ever, thank you for your
>> detailed input.) The pattern I use above (with ".in +4n/.in" was a
>> hack that I cam up with to get code blocks with a "suitable"
>> indent. Your suggestion of ".RS 4/.RE" (in your patch, which I've
>> quoted inline below), does seem better. I'm not averse to changing
>> things. But, there is a related question. I use a similar hack in
>> the SYNOPSIS of many pages (e.g., chmod.2), to undent a single
>> line:
>>
>> [[
>> .PP
>> .in -4n
>> Feature Test Macro Requirements for glibc (see
>> .BR feature_test_macros (7)):
>> .in
>> .PP
>> ]]
>>
>> Presumably, that could be replaced with ".RS -4/.RE", but is
>> there something even better?
> 
> You're correct; .RS honors a negative indentation argument.  So you
> could do this and I would consider it an improvement because it reduces
> the number of lexemes that man page readers--human and machine
> alike--have to comprehend.

I've done it.

> 
> I noticed something about "Feature Test Macro Requirements for glibc",
> however...
> 
> Because of the negative indent, it's within one en of the indentation of
> a subsection (.SS) heading; in fact it's an exact match on nroff devices
> (terminals).  I'm guessing that wasn't an accident.  You're even already
> title-casing it like a heading.
> 
> If you used .SS, it look much the same but end up in bold.
> 
> Admittedly the parenthetical man page cross-reference fits poorly with a
> subsection heading, in part because the font style change would be
> obscured.  

(Yes, I'm not so keen on that.)

> However, I think that could be moved to the _end_ of the
> synopsis with little loss.  It doesn't take seasoned readers of section
> 2 and 3 man-pages documents long to internalize this knowledge about
> feature_test_macros(7), so repeating it by rote in the current
> pseudo-heading may not be helping much.  Inexperienced readers need to
> read closely anyway, and experienced ones already know this information.

Possibly you are right, but that's a bigger global edit that I 
won't attempt for now.

> I notice that in these feature test macro areas you're making heavy use
> of .ad and .br requests, as well as the deprecated .PD macro to set the
> inter-paragraph spacing to zero.  However, that's probably a digression
> for another thread... :)

I think the words you were looking for are "disgusting hack" :-).
Feel free to start another thread...

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

  reply	other threads:[~2020-09-29 13:12 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-20 21:40 [PATCH] system_data_types.7: Add note about length modifiers and conversions to [u]intmax_t, and corresponding example Alejandro Colomar
2020-09-21  5:39 ` Michael Kerrisk (man-pages)
2020-09-21  7:32   ` man-pages.7: Simplify indentation of structure definitions, shell session logs, and so on Alejandro Colomar
2020-09-21  7:49     ` Michael Kerrisk (man-pages)
2020-09-21 14:15       ` G. Branden Robinson
2020-09-24  8:15         ` Michael Kerrisk (man-pages)
2020-09-27  6:03           ` G. Branden Robinson
2020-09-29 13:12             ` Michael Kerrisk (man-pages) [this message]
2020-09-29 20:15         ` Michael Kerrisk (man-pages)
2020-09-30 12:02           ` G. Branden Robinson
2020-09-30 12:54             ` G. Branden Robinson
2020-10-01  7:33               ` Michael Kerrisk (man-pages)
2020-10-26  7:00                 ` Michael Kerrisk (man-pages)
2020-09-21  8:19   ` [PATCH v2] system_data_types.7: Add note about length modifiers and conversions to [u]intmax_t, and corresponding example Alejandro Colomar
2020-09-21  8:29     ` Alejandro Colomar
2020-09-21 10:38     ` Michael Kerrisk (man-pages)
2020-09-21 13:32       ` [PATCH v3] " Alejandro Colomar
2020-09-21 14:13         ` Michael Kerrisk (man-pages)
2020-09-21 14:39           ` Alejandro Colomar

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=f4180fa9-2154-53ee-b29b-580d4d1dc662@gmail.com \
    --to=mtk.manpages@gmail.com \
    --cc=g.branden.robinson@gmail.com \
    --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.