Hi Branden and Alejandro,
G. Branden Robinson wrote on Thu, Oct 26, 2023 at 10:28:13AM -0500:
> At 2023-10-26T16:58:13+0200, Alejandro Colomar wrote:
>> On Thu, Oct 26, 2023 at 09:51:40AM -0500, G. Branden Robinson wrote:
>>> At 2023-10-26T16:12:36+0200, Alejandro Colomar wrote:
>>>> Regarding PP, LP, and P, what's the history of them? Why do we
>>>> have the 3? I'm willing to reduce them to just one.
>>> Doug's original man(7) (1979) didn't have `P`. But Unix System III
>>> added it in 1980, and 4.3BSD followed suit in 1986. This
>>> information is in groff_man(7).
>> Was the original PP?
> It had both `PP` and `LP`.
>> Still, compatibility with ms(7) would make it slightly easier to
>> trasnfer learning from man(7) to ms(7), would one learn it. I know
>> many other macros are incompatible in bad ways, but the less the
>> better, no?
> That's true, but these days the knowledge transfer is, I submit, vastly
> more likely to go the other way; that is, people will be exposed to
> man(7) as their first roff macro language, and might decide to pick up
> ms(7).
>
> At that point, they'd have to learn that `LP` and `PP` do _different_
> things. I think it's actually better if they _don't_ have to unlearn
> the "fact" (applicable only to man(7)) that they are exactly the same.
>
> Better, I believe, to promote only `P` in man(7). Anyone wanting to
> pick up mm(7) will still enjoy some knowledge transfer. Without
> arguments, `P` in mm(7) "does what you mean".
I consider this a bikeshed discussion.
Given that Branden apparently wants to
* promote .P and deprecate .PP
* i don't want mandoc_man(7) to gratuitiously spread any more bad
man(7) style advice than is unavoidable by the fundamental decision
of declaring the whole man(7) language as obsolete,
i briefly considered changing mandoc_man(7).
Currently it says:
PP Begin an undecorated paragraph. The scope of a paragraph is closed
by a subsequent paragraph, sub-section, section, or end of file.
The saved paragraph left-margin width is reset to the default.
LP A synonym for PP.
P This synonym for PP is an AT&T System III UNIX extension later
adopted by 4.3BSD.
and it declares LP and P deprecated by including only PP in the
MACRO OVERVIEW.
All the arguments feel weak in either direction:
* In theory, .PP is more portable than .P, but that is extremely
unlikely to ever matter in practice.
* As seen above, the similarities and subtle differences
when comparing to ms(7) can be employed as arguments in either
direction.
* The arguably more important similarity that HTML defines a <p>
but not a <pp> element can be regarded as a learning aid,
but it's still a weak argument because HTML and roff(7) are
very different domains and not similar in most other respects.
* The similarity of .P and <P> can also be turned around to be
levied as an argument for .PP: .P and <P> are *very different*
in so far as <P> is a block element, whereas .P is an in-line
macro that cannot participate in block nesting. In particular,
it can neither nest inside a list item, nor can anything be
contained inside a .P syntax tree node. In contrast to <p>,
.P does not represent a *paragraph*, but only a paragraph *break*.
* .PP is more similar to mdoc(7) .Pp. Again, a weak argument because
macro naming is totally different in both languages even in most
of the few cases where functionality matches, with the exception
of only .SH and .SS.
Consequently, i tend to leave mandoc_man(7) just as it is and not
repaint the bikeshed. That way, the original .PP macro - with which
nothing is really wrong, except for the fundamental design mistake
of not being a block macro, a mistake it shares with mdoc(7) .Pp -
gets the full description, while the slighly younger .P gets the
compat info, even though that now is only of historical but not
of practical interest. Maybe still nice to keep both apart - gee,
yet another weak argument.
If, for some reason, you feel strongly about it and think it is
important which one to promote, it might be possible to convince me to
deprecate .PP and list .P as the non-deprecated form even though it
is theoretically less portable. I must admit i don't particularly
like the idea, though. It feels like taking a gratuitious risk,
which does not feel ideal even if both the magnitude of the risk
and the benefit reaped are almost exactly zero.
Yours,
Ingo
