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.robin...@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 >