Re: mandoc -man -Thtml bug: inconsistent vertical space before .TP

[Alejandro Colomar]

On Thu, Oct 26, 2023 at 06:37:58PM +0200, Ingo Schwarze wrote:
> That is completely true, and my point 5 is completely bogus.  This is
> embarrassing, in particular since it also tainted the commit message.
> I'm not completely sure how the wrong idea entered my head, possibly by
> confusing .TP and .IP, which i tend to confuse regularly, even though
> the mnemonics isn't actually bad (.TP is the one that can *only*
> be reasonably used for lists with a tag, i.e. the one with mandatory
> next-line syntax, whereas .IP is the one that can be used for any
> indented paragraph, even without a tag).  Not an excuse of course,
> i should have looked more closely and not jumped to wrong conclusions.

No problem.  You're not a man(7) expert, as well as I'm no mdoc(7)
expert, so we can very well be off some days.  :)

> My points 1. to 4. remain valid, but that only means .TQ should not
> be used excessively.  The fact that my point 5 was bogus means
> that avoiding it almost completely is not required.
> Indeed, reasonable use cases seem the same as for .Bl -compact
> with seletive .Pp.  The semantic downside of having a list
> entry with an empty body instead of having an item header consisting
> of two lines is also the same in both languages.  Then again, while
> treating an empty item body as an indication for semantic formatters
> that the following body has two tags is a burden on formatters, it's
> probably not too heavy to bear, so inventing new syntax to avoid that
> burden is likely not reasonable.

I guess your opinion about the recent patch where I changed commas into
2-tag paragraphs is not so bad now, right?

Did you have a chance to check the patch that I'm about to push where I
reorder the options to put short options in the second tag, to make it
more appealing visually (less quasi-blank lines)?

I made a mistake when sending the patch, so I only sent it to the list,
forgetting to CC you, and bounced it to you afterwards, but maybe spam
filters got it, since you're not in the To or Cc list.  Anyway, you have
it here: <https://lore.kernel.org/linux-man/ZTkvKoqSTD9VivQe@debian/T/#u>.

> > Some Linux kernel hackers and other, ehrm, "stakeholders" might take
> > exception to your implication that the Linux man-pages endeavor is a GNU
> > project; it is not.  (It _does_ document a great deal of the GNU C
> > library nevertheless; this is the product of Info champion Richard
> > Stallman's immovable object meeting experienced Unix and GNU/Linux
> > developers' irresistible force demanding man pages.)
> 
> Oops, right.  Groff being a GNU project and groff on the one hand and
> Kerrisk + Colomar on the other hand cooperating so closely (which is
> also a very reasonable thing to do) i fell into another trap here.
> Sorry for that.

I may have contributed to the confusion, by changing the title of the
releases from

        man-pages-5.13.tar.gz - man pages for Linux

to

        man-pages-6.01 - manual pages for GNU/Linux

And the book says on the first page:

        GNU/Linux
        The man-pages book

The reason for that is that the project was too tied to Linux, but half
of it documents GNU, so it also felt a bit insulting to GNU (IMO) to not
even mention it.  So I added it.  I hope that helps get more
contributions from glibc programmers.  :)


Cheers,
Alex

> 
> > But that's just a nit about the commit message.  It's well down the list
> > of wrong things OpenBSD developers have said about GNU.  ;-)
> 
> Heh.  :-/
> 
> Misinformation is never good, no matter where it comes from.
> 
> Yours,
>   Ingo

-- 
<https://www.alejandro-colomar.es/>

signature.asc
Description: PGP signature