The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
To: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] Proliferation of options is great simplification of pipes, really?
Date: Tue, 23 Feb 2021 08:14:29 +1100	[thread overview]
Message-ID: <20210222211427.dpdkjxv72ojnmpuu@localhost.localdomain> (raw)
In-Reply-To: <CAC0cEp-urPFt93eNNtFFoS3=yVCc4Ts8ijgvZ4uDzs4R9R7M4Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]

Hi John,
At 2021-02-22T10:49:52-0500, John P. Linderman wrote:
> I can imagine a simple perl (or python or whatever) script that would
> run through groff input, determine which preprocessors are *actually*
> needed, and set up a pipeline to run through (only) the needed
> preprocessors in the proper order.

This is _almost_ what the groff grog(1) command does.  It's been present
as far back as our history goes, to groff 1.02 in June 1991.

* It's a Perl script.
* It uses pattern-matching heuristics to infer which arguments groff(1)
  will need to format the document (not just for preprocessors, but
  macro packages as well).
* Depending on its own options, it writes the constructed command to
  stderr, executes it, or both.

The only thing it doesn't handle is ordering, because groff(1) already
takes care of that.

> I wouldn't have to tell groff what preprocessors I think are needed,
> and groff wouldn't have to change (although my script would) when
> another preprocessor comes into existence. Modern processors are fast
> enough, and groff input small enough, that the "extra" pass wouldn't
> be burdensome. And it would take the burden off me to remember exactly
> which preprocessors are essential. -- jpl

We don't get a lot of bug reports about grog.  Maybe it's not given
enough prominence in groff's own documentation.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2021-02-22 21:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-22  2:34 Will Senn
2021-02-22  3:32 ` G. Branden Robinson
2021-02-22  4:32   ` Dan Stromberg
2021-02-22  4:34   ` Will Senn
2021-02-22  5:45     ` G. Branden Robinson
2021-02-22 15:49   ` John P. Linderman
2021-02-22 15:57     ` William Cheswick
2021-02-22 16:03       ` John P. Linderman
2021-02-22 21:16         ` G. Branden Robinson
2021-02-22 16:02     ` Warner Losh
2021-02-22 16:12     ` Robert Clausecker
2021-02-22 17:15       ` John Cowan
2021-02-23  0:24       ` Steffen Nurpmeso
2021-02-22 21:14     ` G. Branden Robinson [this message]
2021-02-22  7:20 ` Rich Morin
2021-02-22 18:27 ` Jon Steinhart
2021-02-22 19:30   ` Richard Salz
2021-02-23  2:47 M Douglas McIlroy
2021-02-23 10:42 ` Jaap Akkerhuis
2021-02-23 13:23   ` Brantley Coile
2021-02-23 13:49 ` Ralph Corderoy
2021-02-23 15:04 Steve Simon
2021-02-24  2:42 ` M Douglas McIlroy
2021-02-24 19:38 Norman Wilson

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=20210222211427.dpdkjxv72ojnmpuu@localhost.localdomain \
    --to=g.branden.robinson@gmail.com \
    --cc=tuhs@minnie.tuhs.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).