From: "DJ Chase" <u9000@posteo.mx>
To: "Ingo Schwarze" <schwarze@usta.de>
Cc: <g.branden.robinson@gmail.com>,
"Alejandro Colomar" <alx.manpages@gmail.com>,
<linux-man@vger.kernel.org>, <groff@gnu.org>
Subject: Re: Standardize roff (was: *roff `\~` support)
Date: Sun, 14 Aug 2022 14:49:10 +0000 [thread overview]
Message-ID: <CM5U2DCMCPL4.38VBYJS3B1L65@grinningface> (raw)
In-Reply-To: <Yvj/CAUSL1jVbAot@asta-kit.de>
On Sun Aug 14, 2022 at 9:56 AM EDT, Ingo Schwarze wrote:
> Hi,
>
> DJ Chase wrote on Sat, Aug 13, 2022 at 05:27:34PM +0000:
>
> > Have we ever considered a de jure *roff standard?
>
> No, i think that would be pure madness given the amount of working
> time available in any of the roff projects.
>
> […]
This is very sad to hear.
> > It could also lead to more users & use cases because existing
> > users could count on systems supporting certain features, so
> > they could use *roff in more situations, which would lead to
> > more exposure.
>
> You appear to massively overrate the importance end-users
> typically attribute to standardization.
That’s probably because *I* massively overrate the importance of
standardization (I mean I literally carry a standards binder with me).
Still, though, it’s rather annoying that end users — especially
programmers — don’t value standards as much.
> > It’s ridiculous that *roff isn’t part of POSIX when it was Unix’s
> > killer feature.
>
> You are welcome to spend the many years required to change that.
> But be aware that some standardization efforts that are part of
> POSIX resulted in parts of the standard that are barely useable
> for practical work. One famous example is make(1).
>
> Don't get me wrong: i think standardization is very nice to have,
> should be taken very seriously when available, and provides some
> value even when the standardization effort mostly failed, like in
> the case of make(1). But standardization is absolutely not cheap.
> To the contrary, it is usually significantly more expensive than
> implementation and documentation.
Would an informal de jure standard be of any use? Like how TOML just has
a specification, but it’s somewhat usable as a standard because it’s
been pretty stable and because it’s written clearly enough.
Cheers,
--
DJ Chase
They, Them, Theirs
next prev parent reply other threads:[~2022-08-14 14:49 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-29 11:45 [PATCH 4/6] xattr.7: wfix Štěpán Němec
2022-07-29 20:58 ` G. Branden Robinson
2022-07-30 14:15 ` Štěpán Němec
2022-07-30 17:53 ` Alejandro Colomar (man-pages)
2022-07-30 17:59 ` Alejandro Colomar (man-pages)
2022-08-01 13:28 ` Alejandro Colomar
2022-08-11 12:48 ` Ingo Schwarze
2022-08-11 20:17 ` G. Branden Robinson
2022-08-12 14:30 ` Ingo Schwarze
2022-08-12 22:10 ` *roff `\~` support (was: [PATCH 4/6] xattr.7: wfix) G. Branden Robinson
2022-08-13 4:23 ` G. Branden Robinson
2022-08-14 14:15 ` Ingo Schwarze
2022-08-14 22:21 ` G. Branden Robinson
2022-08-13 17:27 ` DJ Chase
2022-08-14 13:56 ` Standardize roff (was: *roff `\~` support) Ingo Schwarze
2022-08-14 14:49 ` DJ Chase [this message]
2022-08-14 16:32 ` Alejandro Colomar
2022-08-14 19:43 ` DJ Chase
2022-08-15 11:59 ` Alejandro Colomar
2022-08-16 11:48 ` Ingo Schwarze
2022-08-14 22:35 ` G. Branden Robinson
2022-08-14 22:58 ` DJ Chase
2022-08-15 0:20 ` Sam Varshavchik
2022-08-16 12:52 ` Standardize roff Ingo Schwarze
2022-08-16 23:46 ` Sam Varshavchik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CM5U2DCMCPL4.38VBYJS3B1L65@grinningface \
--to=u9000@posteo.mx \
--cc=alx.manpages@gmail.com \
--cc=g.branden.robinson@gmail.com \
--cc=groff@gnu.org \
--cc=linux-man@vger.kernel.org \
--cc=schwarze@usta.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.