I've noticed that grog(1) will suggest options for preprocessors
irrespective of whether they're even available on the user's system. Some
aren't part of Groff, like grap(1). Others are excluded from certain base
installations — Ubuntu Server, for example, ships with pic(1) and tbl(1),
but omits ch
Am 08.08.2019 17:16, schrieb John Gardner:
> I've noticed that grog(1) will suggest options for preprocessors
> irrespective of whether they're even available on the user's system. Some
> aren't part of Groff, like grap(1). Others are excluded from certain base
> installations — Ubuntu Server, f
Hi John,
> I've noticed that grog(1) will suggest options for preprocessors
> irrespective of whether they're even available on the user's system.
That seems fair enough. The rest of the system is used to being asked
to run programs that don't exist and report that to the user in a
familiar mann
> loadVersion()'s regexp can be simplified because `xx*' is `x+'. :-)
Well-spotted refactoring error, thank you. ;-)
> I didn't read all the way through that page and ended up skimming it.
> You use grog if it's available, falling back on your own logic to
> analyse the troff source.
The fallba
Hi John,
> > > https://github.com/Alhadis/Roff.js/blob/8678ef365626e049c58b4ad65d62383fe7db49b9/lib/adapters/troff/groff.mjs#L575
> >
> > What's the problem with grog suggesting something that isn't
> > installed?
>
> Rendering needs to succeed even if the necessary preprocessors aren't
> installe
> So it all works as is now you've written the code, you're just pointing
> out that grog's current behaviour meant you had to take this route?
I was basically explaining how this could be an issue instead of a minor
annoyance.
In my particular case, I need to support multiple Groff versions, so
