All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <colomar.6.4.3@gmail.com>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>,
	"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: linux-man@vger.kernel.org, libc-alpha@sourceware.org
Subject: Re: [PATCH 1/3] system_data_types.7: ffix
Date: Mon, 28 Sep 2020 12:51:08 +0200	[thread overview]
Message-ID: <7fd6e906-8050-b1a8-96e9-a4866965bdd7@gmail.com> (raw)
In-Reply-To: <20200928104016.za36rrtmgb55bh3v@localhost.localdomain>

Hi Branden,

On 2020-09-28 12:40, G. Branden Robinson wrote:
 > At 2020-09-28T07:59:14+0200, Michael Kerrisk (man-pages) wrote:
 >>> Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>
 >>
 >> I do think this requires an explanation saying what you are
 >> trying to do with this change (and then perhaps a more expansive
 >> "Subject" also).
 >>
 >> I can visually see what you are doing with this patch,
 >> but I do wonder if there is a better way of doing it.
 >>
 >> I've dropped Branden into CC. Perhaps he has a comment.
 >
 > Hi Michael, yes--thank you!
 >
 > In my opinion, use of "raw" *roff requests in a man page is a "code
 > smell".
 >
 > Let me have a look...
 >
 >>> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
 >>> index 361e8d411..ff0403df9 100644
 >>> --- a/man7/system_data_types.7
 >>> +++ b/man7/system_data_types.7
 >>> @@ -66,7 +66,7 @@ system_data_types \- overview of system data types
 >>>   .TP
 >>>   .I aiocb
 >>>   .RS
 >>> -.PP
 >>> +.br
 >>>   Include:
 >>>   .IR <aio.h> .
 >>>   .PP
 >
 > This is changed already from my most recent "git pull", so things are
 > moving fast indeed in this area!  Here's what I show currently:
 >
 > .\"------------------------------------- aiocb ------------------------/
 > .TP
 > .I aiocb
 > .IP
 > Include:
 > .IR <aio.h> .
 > .IP
 > .EX
 > struct aiocb {
 >
 > So first the indented paragraph was replaced (or proposed to be
 > replaced) by a relative inset (.RS) and a paragraph break (.PP).  It's
 > not visible in this diff where the relative inset ends, but I reckon
 > it's right before the next tagged paragraph (.TP).
 >
 > Now, the .PP is being replaced by .br, I guess because you want to
 > eliminate some vertical space between the paragraph tag ("aiocb" in
 > italics above) and the following material?
 >
 > However, .TP already does this for you when the tag is wider than the
 > paragraph indentation.  You probably discovered this yourself with
 > "ptrdiff_t".
 >
 > I get the feeling you're going for something specific in terms of visual
 > presentation.
 >
 > What is it that you don't like about the following pattern?
 >
 > .TP
 > .I typename_t
 > Include
 > .IR <header.h> .
 > .IP
 > .EX
 > struct typename {
 >      // ...
 > }
 > .EE
 > .IP
 > Notes and commentary.

That's the first thing we tried; actually if I remember correctly,
that's what Michael suggested first.

But as you said, when we documented types with a long name such as
ptrdiff_t, the alginment broke: sometimes Include was in the same line,
and sometimes in the next one.

That's when we opted for

.\"------------------------------------- aiocb ------------------------/
.TP
.I aiocb
.IP
Include:
.IR <aio.h> .
.IP
.EX
struct aiocb {



 >
 > The above visually aligns everything by the type name with all the
 > material related to each type inset, which makes the page easy to scan.
 > Literal code is not filled, so code indentation is respected and (on
 > typesetters) the code be in a monospaced font so it will stand out and
 > align correctly.  You don't have to manage insets with .RS and .RE, and
 > you can still have as many paragraphs as you want with .IP.


Then, a few days ago, I pushed the change that you still didn't see:
Replace .IP with .RS/.RE + .PP

I'll refer to the patch for the rationale: it was a bit long. Basically,
it better represents a whole block, and it's easier to further indent:

https://lore.kernel.org/linux-man/16c0890e-33c0-d052-d7ee-39385cd79299@gmail.com/T/#m21da4dba4b3a44b0a59cad1e7eacb13a68a91636

This change actually didn't have visual effects; just source changes.

 >
 > I have some guesses as to what might be bothering you, but I don't want
 > to put words in your mouth, and my mails tend to run too long anwyay, so
 > I won't voice them right now.  :)
 >
 > Regards,
 > Branden
 >

Thanks,

Alex

  reply	other threads:[~2020-09-28 10:51 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-27 21:13 [PATCH 1/3] system_data_types.7: ffix Alejandro Colomar
2020-09-27 21:13 ` [PATCH 2/3] system_data_types.7: Add 'FILE' Alejandro Colomar
2020-09-28  6:04   ` Michael Kerrisk (man-pages)
2020-09-28  9:06     ` [PATCH v2 " Alejandro Colomar
2020-09-29 13:15       ` Alejandro Colomar
2020-09-29 13:35         ` Michael Kerrisk (man-pages)
2020-09-27 21:13 ` [PATCH 3/3] FILE.3: New link to system_data_types(7) Alejandro Colomar
2020-09-28  5:59 ` [PATCH 1/3] system_data_types.7: ffix Michael Kerrisk (man-pages)
2020-09-28  9:03   ` [PATCH v2 " Alejandro Colomar
2020-09-28 10:34     ` Michael Kerrisk (man-pages)
2020-09-28 10:37       ` Alejandro Colomar
2020-09-28 11:13       ` G. Branden Robinson
2020-09-28 13:06     ` G. Branden Robinson
2020-09-28 13:44       ` Alejandro Colomar
2020-09-30 10:43         ` G. Branden Robinson
2020-09-30 21:32           ` Alejandro Colomar
2020-10-01  7:37             ` Michael Kerrisk (man-pages)
2020-10-01  7:52               ` Alejandro Colomar
2020-10-01  9:36                 ` Michael Kerrisk (man-pages)
2020-09-28 10:40   ` [PATCH " G. Branden Robinson
2020-09-28 10:51     ` Alejandro Colomar [this message]
2020-09-28 12:49       ` G. Branden Robinson
  -- strict thread matches above, loose matches on Subject: below --
2020-09-18 13:29 [PATCH 0/3] Document regmatch_t (and a ffix) Alejandro Colomar
2020-09-18 13:29 ` [PATCH 1/3] system_data_types.7: ffix Alejandro Colomar
2020-09-18 20:42   ` Michael Kerrisk (man-pages)

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=7fd6e906-8050-b1a8-96e9-a4866965bdd7@gmail.com \
    --to=colomar.6.4.3@gmail.com \
    --cc=g.branden.robinson@gmail.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    /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.