Hi Larry, At 2025-02-20T16:49:47-0800, Larry McVoy wrote: > On Thu, Feb 20, 2025 at 06:36:29PM -0600, G. Branden Robinson wrote: > > At 2025-02-20T19:39:37+0100, onf wrote: > > > On Thu Feb 20, 2025 at 5:59 PM CET, Douglas McIlroy wrote: > > > > The idea that the argument of .so might contain unquoted spaces > > > > is anathema--contrary to groff convention and fortunately not > > > > supported. > > > > > > As far as I know, .so currently doesn't support spaces even when > > > quoted. > > > > That's correct, and true of all troffs known to me. > > > > GNU soelim has long supported a backslash escaping convention for > > spaces, but that convention is not recognized by any known troff, > > making for awkwardness; it seems pretty counterintuitive to me to > > have the `so` request work differently depending on whether it's > > soelim or the formatter that interprets it. > > Yeah, I had a lapse of judgement, you and Doug are correct. Would > something like > > .so "/path/to/file with spaces in the name" 2-11 > > or > > .so '/path/to/file with spaces in the name' 2-11 > > be acceptable?
Difficult to do in the formatter because it tries not to scan ahead in
its input. If someone replaced the `so` request with a macro (likely
after renaming the real `so`), then the former case, with double quotes,
becomes way more feasible and it sounds from the thread like some people
have already implemented that.
There are two syntactical provisions missing from the formatter that
foreclose what you have in mind.
1. There's no such thing as a quoted argument to a request. `ds` and
`as` support a leading `"` to permit an argument to start with
space(s); that's otherwise syntactically impossible because spaces
separate request arguments and any that are present have been
skipped over by the time a request argument is processed. But in
every case where a leading `"` has this meaning (and is discarded),
the entire remainder of the input line is read (in copy mode) into
the argument--including spaces (but excluding comments).
2. There's no provision for altering the macro argument quotation
character. It's `"`, forever and always.
> My roff-fu is weak these days, I know pic liked double quoted strings
In groff, and I think everywhere else too, each preprocessor implements
its own bespoke input parser. Some use YACC grammars (pic, eqn) and
others don't (tbl, soelim).
> but if roff is single quote, that's fine, I don't care.
It's worse than you think. There's just no such thing as quotation in
requests in *roff--not in the sense we know it from C or the shell.
Even a backslash often doesn't "quote" the character after it, but
frequently transforms its meaning into a completely different kind of
token. For example, an "f" and an escaped "f" have wildly different
semantics.
It may be worth mentioning at this point that *roff is _older_ than the
C language or the Unix shell, and even Ossanna's nroff is, in its
initial version, contemporaneous with the earliest implementations of
the C compiler and Unix shell that existed.
There's a really neat thread on TUHS that popped up just today[1]
regarding the resurrection of an ultra-early, barely-working form of the
Ritchie C compiler that introduced structs (with scandalous syntax) and
the `*` notation for pointer dereference.
When considering these syntactical issues, we're scrutinizing decisions
that were made over 50 years ago--though to my regret I can't put a date
on the birth of the *roff escape sequence. I _think_ it's an nroff
innovation but it is hard to date with precision because the nroff
manual (cf. its man page) did not officially exist for several years,
and apparently did not get archived in any of its preliminary forms.
> I just know, from supporting software on Windows and Macs, those users
> sprinkle spaces everywhere.
Yes. That is why I wanted to make GNU troff able to cope with them.
Regards,
Branden
[1] https://www.tuhs.org/pipermail/tuhs/2025-February/031428.html
signature.asc
Description: PGP signature
