All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: Sam Varshavchik <mrsam@courier-mta.com>
Cc: DJ Chase <u9000@posteo.mx>,
	g.branden.robinson@gmail.com,
	Alejandro Colomar <alx.manpages@gmail.com>,
	linux-man@vger.kernel.org, groff@gnu.org
Subject: Re: Standardize roff
Date: Tue, 16 Aug 2022 14:52:03 +0200	[thread overview]
Message-ID: <YvuS8w3yYOuj9tWF@asta-kit.de> (raw)
In-Reply-To: <cone.1660522834.354716.280603.1004@monster.email-scan.com>

Hi San,

Sam Varshavchik wrote on Sun, Aug 14, 2022 at 08:20:34PM -0400:
> Ingo Schwarze writes:
>> 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.

> I tinkered with something like this some years ago, but I took a slightly  
> different approach.
> 
> I converted man pages

What kind of manual pages?

> from 'roff source to Docbook XML using a … pretty large Perl script.

That sounds very foolish on several levels.

First, and most obviously, you seem to be duplicating esr@'s work
on doclifter:

  http://www.catb.org/~esr/doclifter/
  https://gitlab.com/esr/doclifter/-/blob/master/doclifter

Second, quick and dirty Perl-style parsing is usually not good
enough to parse roff code, and a huge script is not particularly
good for readability and maintainability.

Yes, i know the same resevations would apply to esr@'s work,
which is a giant Python 3 script.  But at least there is some
evidence that his work was able to find significant numbers of
real issues in real manual pages.

> Once a year, or so, when I have nothing better to do I pull the current
> man  page tarball and reconvert it. I usually need to tinker the Perl
> script, here and there, each time.
> 
> The Docbook folks provide a stylesheet that converts Docbook XML
> back to 'roff.

Yikes.  That thing is by far the worst man(7) code generator existing
on this planet.  If at all possible, you should avoid that toolchain
like the plague.

It is so bad that for years, bogus reports caused by that totally
broken toolchain have caused the majority of invalid mandoc bug
reports.

> The end result you get is standardized 'roff, whatever that means.

Absolutely not.  The result is utter crap.  It is rarely even
syntactically valid, let alone reasonable style.

> But, yes, the effort require to clean up and standardize the formatting
> of man pages would be mammoth. There's more inconsistency across the
> various man pages, from various sources, than consistency.

That isn't completely untrue, but all the same, mandoc copes well
enough with more than 95% of valid real-world manual pages, and groff
with 100%.  In a nutshell, the only stuff that breaks with groff
is manual pages that are completely invalid, usually coming from
the official DocBook XML toolchain, and in rarer cases coming from
other broken man(7) generators.

All this is barely related to the question of standardizing roff(7),
though.  Roff is much more than manual pages.

Yours,
  Ingo

  reply	other threads:[~2022-08-16 12:52 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
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                       ` Ingo Schwarze [this message]
2022-08-16 23:46                         ` Standardize roff 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=YvuS8w3yYOuj9tWF@asta-kit.de \
    --to=schwarze@usta.de \
    --cc=alx.manpages@gmail.com \
    --cc=g.branden.robinson@gmail.com \
    --cc=groff@gnu.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mrsam@courier-mta.com \
    --cc=u9000@posteo.mx \
    /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.