At 2025-02-19T16:46:51-0800, Larry McVoy wrote: > On Wed, Feb 19, 2025 at 11:46:30PM +0000, Neil Johnson wrote: > > With my alternative syntax: > > > > .SO[2-11] /my/source/file > > .SO[40-50] /my/source/file > > .SO[...] /my/source/file > > I like this form. Though the other way you could do it is > > .SO /my/source/file\ with\ spaces\ in\ the\ name 2-11,40-50,...
This has the disadvantage that `\ ` is tokenized as an ubreakable space
and thus remains in the macro argument.
I did the following interactively; a here document runs into escaping
problems that I didn't want to mess with.
$ groff -T utf8
.de foo
.while \\n[.$] \{\
. tm foo got arg "\\$1"
. shift
.\}
..
.foo bar\ baz\ qux 2-11
Output to stderr:
foo got arg "bar\ baz\ qux"
foo got arg "2-11"
To scrub the backslashes out requires a string iterator, which we don't
yet have[1] or a tedious,[2] error-prone,[3] and non-portable[4] manual
procedure.
Fortunately, a `SO` _macro_ can simply double-quote the multi-word
argument.
> For the record, I like your way better.
>
> .so[2-11] /my/source/file with spaces in the name
>
> My opinion is what it is, but I'd prefer a .so[2-11] since it can be
> backwards compat with .so /my/file.
I think that the situation is more difficult than that because, for
instance, "2-11" is a legitimate Unix file name. You must count
arguments to know which mode of operation to use. This is easy to do
for a macro (just inspect `\n[.$]`) but more tedious in the formatter
itself, which tries very hard to avoid scanning ahead in the input.
Regards,
Branden
[1] https://savannah.gnu.org/bugs/?62264
[2] https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/an.tmac?h=1.23.0#n500
[3] https://savannah.gnu.org/bugs/?65469
[4] The macro shown in [2] uses the groff extension requests `return`
and `while`, and whereas the logic could conceivably be rewritten to
avoid them, it also uses the extension request `substring`, which is
difficult-to-impossible to simulate in AT&T troff.
signature.asc
Description: PGP signature
