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

[Alejandro Colomar <alx.manpages@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2506 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]