groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Standardize roff (was: *roff `\~` support)


From: Alejandro Colomar
Subject: Re: Standardize roff (was: *roff `\~` support)
Date: Mon, 15 Aug 2022 13:59:24 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.1.0

Hi,

On 8/14/22 21:43, DJ Chase wrote:
True; prescriptive standards can certainly make some things worse. As a
further example, ISO 8601 sucks. I mean, its core specification is
great, but there are so many different ways that are allowed that the
full standard is almost completely unparseable. It also uses a slash
between the start and end times of a period instead of something
sensible, like, I don’t know, an en-dash! Which means that periods can
be written with a slash (because that’s the standard) but also with an
en-dash (because that’s how ranges work in English), but also that one
can’t properly write a period in a file name or URI.

Still, though, I think descriptive standards can be net-positive. The
POSIX shell utilities comes to mind. Sure, they certainly have some
issues, but because it’s a trailing standard, implementers are free to
fix them.

Do you think that a descriptive/trailing standard could be beneficial
or would you still say that it could mostly hinder *roff
implementations?

Well, a standard that truly recognizes the authority of implementations to drive the language and doesn't do anything else but describe the best already-implemented ways to achive things is a good thing. It can't hinder future implementations, because it doesn't have the power to drive the future of the language, only describes the past.

POSIX C has been doing good in that; much better than ISO C.

I don't understand how POSIX works internally, though. If some entity can fund (and is interested in) such a standardization process, it could bring some good. But yeah, it will likely be very costly in time and money. Worth it? I don't know.

But we can achieve something very similar by documenting the differences between known roff alternatives somewhere. And that's likely to be much easier.

In the Linux man-pages we document when a function is in ISO C or in POSIX, but also when it's not standardized but present in other Unix systems (so that it has some degree of portability), or when it is Linux-only. Maybe having something similar in groff's manual pages would be effective.

For example, for .MR, we were discussing that probably it would be good to add a note like "(since groff 1.23.0)" and maybe it could also state which other roff (or mandoc) implementations support it.

Cheers,

Alex

--
Alejandro Colomar
<http://www.alejandro-colomar.es/>

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]