All of lore.kernel.org
 help / color / mirror / Atom feed
From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
To: Alejandro Colomar <colomar.6.4.3@gmail.com>
Cc: mtk.manpages@gmail.com, linux-man@vger.kernel.org,
	libc-alpha@sourceware.org
Subject: Re: [PATCH v2 1/3] system_data_types.7: ffix
Date: Wed, 30 Sep 2020 20:43:24 +1000	[thread overview]
Message-ID: <20200930104322.6ffed5lw3uqmlzph@localhost.localdomain> (raw)
In-Reply-To: <1fe937db-8874-a8fb-5e65-88b4b15702fe@gmail.com>

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

At 2020-09-28T15:44:46+0200, Alejandro Colomar wrote:
> I did mean .SH:
> 
> For each type we're separating the paragraphs by description,
> conforming to, see also, ...  similar to the .SH sections.

Okay, I see; you were using an analogy.

> And therefore, I thought that we should use the same format for
> consistency: After the title, or in this case the tag,
> there should be no blank line.
> 
> However, if using .br is a big headache, I would rather not use
> workarounds (as you proposed in an earlier email),
> and instead just live with the blank line.  It's not much of a
> problem.

Was an actual decision taken on this?  I see patches continuing to roll
in containing this .br-based pattern.  I think if the extra line is
live-withable, it should be lived with (or one of my four proposed
alternatives could be used :) ), in preference to setting the bad
example of the "naked" .br requests.

man page markup is highly prone to cargo-culting; on the groff list not
too long ago, some sleuthing revealed an example of a typo that crept
into the X Window System man pages over 30 years ago and was not only
diligently retained there but faithfully copied elsewhere by people who
didn't realize what they were copying[1].

> I leave it up to you to decide what to do, Michael.
> 
> My proposals:
> If you prefer consistency in the source, I'd rather not use
> workarounds: I'd just leave .PP, and accept the blank line
> I see those workarounds uglier than .br.

Too bad for me.  But I admit I'm not proud of that .TQ thing.  :P

> If you however prefer consistency in the visual page,

That's not how it appears to me; I may be bringing too much insider
knowledge to the question, but I know when I see them that the things
you've termed section headings aren't true section headings.  Primarily
I can tell by the fact that their indentation is wrong for an .SH macro.

But the knowledge isn't all that far inside.  The worst hand-written man
page I have ever seen in my life, or expect to see, was written by
Albert Cahalan, who hated *roff with a passion I have reserved only for
love affairs.  He learned just enough of the language to subvert man-db
and groff into accepting his plain-text document as a man page[2].

I don't know what ever became of Mr. Cahalan, but I imagine that he is
somewhere working on processing Markdown with XML:FO and enjoying
himself immensely.

Regards,
Branden

[1] https://lists.gnu.org/archive/html/groff/2019-03/msg00047.html
[2] https://gitlab.com/procps-ng/procps/blob/7ac9a0e1f5606696dc799b773d5ec70183ca91a3/ps/ps.1


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

  reply	other threads:[~2020-09-30 10:43 UTC|newest]

Thread overview: 22+ 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 [this message]
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
2020-09-28 12:49       ` 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=20200930104322.6ffed5lw3uqmlzph@localhost.localdomain \
    --to=g.branden.robinson@gmail.com \
    --cc=colomar.6.4.3@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.