Re: Proposed: simplify `mso` request

[John Gardner]

Hi Branden,

Wouldn't this conflict with behaviour documented in groff_tmac(5)? From the
section *"Inclusion"* (emphasis mine):

GNU troff offers an improved feature in the similar request “*mso*
> *package-file-name*”, which searches the macro path for
> *package-file-name*. Because its argument is a file name, its “.tmac”
> component must be included for the file to be found; *however, as a
> convenience, if opening it fails, mso strips any such suffix and tries
> again with a “tmac.” prefix, and vice versa.*


I'm normally averse to changing documented behaviour without a compelling
motivation to do so; however, I admit that falling back on tmac.s when
s.tmac isn't found is rather unintuitive behaviour, and it doesn't strike
me as wise to mix modern Groff extensions with AT&T-era warts. So I'm
leaning tentatively in favour of this change.

— John

On Fri, 23 Feb 2024 at 07:52, G. Branden Robinson <
g.branden.robinson@gmail.com> wrote:

> I'd like to suggest the attached diff.
>
> What removing this code would do is make the `mso` request no longer
> look for "tmac.s" if "s.tmac" is specified as the request's argument,
> and vice versa.
>
> Here's my case against.
>
> 1.  It's needless complexity.
> 2.  The main things you'd need this for are full-service traditional
>     macro package names on AT&T troff environments, where they're
>     (sometimes) named "tmac.s", "tmac.an", and so forth.
> 2a. Except not all AT&T troff environments name them that way.  DWB 3.3
>     troff, for instance stores them without "tmac" in the name at all.
>
>     $ ls ~/dwb/lib/macros
> an
> color
> csmacros
> mmn
> mmt
> pictures
> ptx
> safe
> strings.mm
> v
> view
>
> 2b. Usually, full-service macro packages are loaded via the command line
>     with the `-m` option, which is still supported, and does the
>     foregoing aggressive search.
> 3.  The `mso` request itself is not portable, but a groff extension.  So
>     this feature is not applicable to the use case of trying to format a
>     read-only legacy *roff document with groff.
> 4.  If you wanted to hack on a legacy *roff document and use this
>     feature to load a macro file from the "macro path", you could
>     equivalently do this.
>
>     .mso s.tmac
>     .mso tmac.s
>
> 5.  But, you may point out, that will probably throw at least one
>     warning, for whichever of these files isn't present on the system.
>     That's harmless, but...
> 6.  As of groff 1.23.0, you can do this.
>
>     .msoquiet s.tmac
>     .msoquiet tmac.s
>
>     ...which won't throw any diagnostics about missing files.
>
> I therefore think this code has outlived whatever utility it had.
>
> N.B., I have zero intention of killing `mso` altogether, just this weird
> feature whereupon failing to open the specified file name, it rewrites
> its argument to go looking for a _different_ file name.
>
> Comments?
>
> Regards,
> Branden
>