Hi Ralph, Ralph Corderoy wrote on Mon, May 23, 2022 at 10:22:58AM +0100: > Doug wrote:
>> I fail to see any case for deprecating .PD. > It seems pointless for GNU Groff to attempt to deprecate .PD when it is > only one of the man-page formatters and has no control over the many > existing man pages. We actually do have partial control over a significant portion of existing manual pages, by virtue of some relevant people participating in the list <groff@gnu.org>. I am (second to jmc@) co-maintainer of the manual pages in the OpenBSD base system, and i regularly have contact to manual page maintainers in FreeBSD, NetBSD, and (rarely, because they appear much less active) DragonFly BSD and Illumos. I do occasionally provide advice to other BSD manual page maintainers, including questions of style, portability, deprecation and the like. Leading developers from the Linux Documentation Project also regularly participate in this list, so we have almost all practically relevant free operating systems covered to some degree. Admittedly and for good reasons, huge numbers of individual, portable software packages also provide manual pages, and we have no direct access to the developers of those. Then again, when those people actively look for advice, they are most likely to look at what we produce, in particular manual pages and style guides included in the groff distribution, in the Linux Documentation project, and in the BSD base systems. So i think that in general, it does make sense for groff to provide style advice and formalize deprecations, even if the time for such advice to spread probably needs to be measured in decades and certainly not in months. Regarding the specific question of deprecating .PD, i suspect it may be better not to, because it causes little harm and has some applications where it is more portable and not significantly more ugly than the alternatives. But i don't feel strongly about that. Regarding new text formatters and markup languages, i don't see much need for them. Over the decades, most other attempts turned out much worse than ROFF and LaTeX, including practically all that are significantly younger, and for software documentation in particular, ROFF remains vastly superior to TeX and to all other, younger solutions i'm aware of. So i think carefully maintaining and slowly evolving the roff-based languages is actually more promising than hoping for Go & friends. Of course, compatibility should only be broken when that is unavoidable for *very* important new functionality. Yours, Ingo
