All of lore.kernel.org
 help / color / mirror / Atom feed
From: "DJ Chase" <u9000@posteo.mx>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>,
	"Ingo Schwarze" <schwarze@usta.de>
Cc: "Alejandro Colomar" <alx.manpages@gmail.com>,
	<linux-man@vger.kernel.org>, <groff@gnu.org>
Subject: Re: *roff `\~` support (was: [PATCH 4/6] xattr.7: wfix)
Date: Sat, 13 Aug 2022 17:27:34 +0000	[thread overview]
Message-ID: <CM52T3SFTBDU.21XFDQOUZP886@grinningface> (raw)
In-Reply-To: <20220812221035.xd4udngmz5erht5p@illithid>

On Fri Aug 12, 2022 at 6:10 PM EDT, G. Branden Robinson wrote:
> Hi Ingo,
>
> At 2022-08-12T16:30:01+0200, Ingo Schwarze wrote:
> > G. Branden Robinson wrote on Thu, Aug 11, 2022 at 03:17:14PM -0500:
> > > At 2022-08-11T14:48:51+0200, Ingo Schwarze wrote:
> > >> The former is portable and the latter is a GNU extension.
> > 
> > > ...that is over 30 years old and supported by Heirloom Doctools
> > > troff for 17 years now, neatroff for about six, and your mandoc for
> > > three.
> > 
> > Actually, mandoc supports \~ at least since Sep 17 2009:
> > https://cvsweb.bsd.lv/mandoc/Attic/chars.in?rev=1.1&content-type=text/x-cvsweb-markup
>
> Whoops!  I regret the error, and will update groff's Texinfo manual to
> correct this.
>
> > > plan9port troff doesn't either, and its laudable introduction
> > > of a man(7) MR macro notwithstanding, its activity level is
> > > not high.
> > 
> > There are people using Plan 9 for practical work though, they have
> > even occasionally posted on the groff and mandoc lists, so that is a
> > bit more of a problem.
>
> […] But, if
> that's what it takes to get this escape sequence de facto standardized,
> and no one else will do it, that will move it up the priority queue.

Have we ever considered a de jure *roff standard? If not, here are just
some reasons:

	•  [the obvious benefits of standardizing anything]
	•  A standard could lead to more implementations because
	   developers would not have to be intimately familiar with the
	   {groff,heirloom,neatroff} toolchain before implementing a
	   *roff toolchain themselves.
	•  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.

Cheers,
-- 
DJ Chase
They, Them, Theirs

PS: It’s ridiculous that *roff isn’t part of POSIX when it was Unix’s
    killer feature.

  parent reply	other threads:[~2022-08-13 17:27 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 [this message]
2022-08-14 13:56                   ` Standardize roff (was: *roff `\~` support) Ingo Schwarze
2022-08-14 14:49                     ` DJ Chase
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=CM52T3SFTBDU.21XFDQOUZP886@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.