I don't intend to address the "line selection by number from a sourced file" issue in this sub-thread. The point here is to increase awareness of developments in the forthcoming groff 1.24.0.
At 2025-02-20T16:28:02-0500, Douglas McIlroy wrote:
> Indeed, .so does not keep a quoted argument together. Surely that's a
> bug.
At 2025-02-20T11:59:09-0500, Douglas McIlroy wrote:
> > .so[2-11] /my/source/file with spaces in the name
>
> The idea that the argument of .so might contain unquoted spaces is
> anathema--contrary to groff convention and fortunately not supported.
Considering the foregoing two messages together, I have good news and
anathematically bad news.
The good news is that groff 1.24.0 will fix the bug you identify.
The bad news is that it will do so via anathematic means.
See the NEWS file entries for the forthcoming groff 1.24.0
release I quoted in response to Neil earlier. For this message, I'll
tuck them into a footnote.[1]
I have a cluster of observations.
1. You're right that the `so` request has not kept a quoted argument
together.
2. Requests and macro calls are not the same thing, and do not have the
same syntax. They are similar enough to be confused with each
other, unfortunately. groff's Texinfo manual cautions the reader
in this regard.[2]
3. To my knowledge, no request in AT&T or GNU troffs has ever supported
a quotation convention in the sense that macro calls do.
4. As a special case, some AT&T troff requests accepted an opening
quotation mark to permit embedding of spaces at the start of a
request argument. But there was no "closing" quotation syntax; all
requests supporting this opening quotation mark scanned the
remainder of the input line into the argument. The `ds` and `as`
requests are best known for this behavior, but a few GNU troff
extensions (like `tm1`) have used it too.
5. I noticed that in all of the places where an AT&T troff or GNU troff
extension request handled a file name as an argument, it was always
positioned last in the argument sequence.
6. That made it possible to generalize two special cases:
6a. acceptance of leading spaces in a file name argument if they were
prefixed with `"`; and
6b. acceptance of embedded spaces in a file name argument.
The last was a simple matter of changing some requests to call a
function that reads to the end of the input line instead of one that
reads a "name"--in other words, the function that normally reads a groff
identifier but gets abused for a variety of space-delimited grammatical
elements.
(Here's a trivia challenge, and one for which I don't already have the
answer: do requests in existing troff implementations read file name
arguments to requests in copy mode or not? Are there any advantages to
not doing so?)
For Savannah ticket traffic motivating, exploring, and arguing these
changes, see:
https://savannah.gnu.org/bugs/?66027 [soelim]
https://savannah.gnu.org/bugs/?66434 [formatter]
https://savannah.gnu.org/bugs/?66673 [documentation]
(even more background is in Savannah #65108, see below)
...and, in vaguely related news...
https://savannah.gnu.org/bugs/?65246 [grops and font description files]
For me, this work was just one step toward more ambitious goals, the
realization of which is some ways off; that is, groff 1.25 or later.
https://savannah.gnu.org/bugs/?65108
https://savannah.gnu.org/bugs/?64071
https://savannah.gnu.org/bugs/?62787
Regards,
Branden
[1]
Noteworthy incompatible changes
-------------------------------
* If your roff(7) documents follow any of the requests `cf`, `hpf`,
`hpfa`, `mso`, `msoquiet`, `nx`, `open`, `opena`, `so`, `soquiet`, or
`trf` with a comment after their file name argument, and did not place
that comment immediately after the file name, you are likely to get a
diagnostic message.
warning: cannot open macro file 'e.tmac ': No such file or directory
Or, less likely, the formatter will open the wrong file, one with
spaces at the end of its name. That is because these requests are now
able to process file names containing space characters. (This change
also makes the request syntax consistent with that of `ds`, `as`, and
others.) A quick fix is to place the comment escape sequence as early
as possible. For example, we would change:
.mso e.tmac \" Load Eric Allman's package.
to:
.mso e.tmac\" Load Eric Allman's package.
to tell the formatter to load the "e.tmac" file rather than "e.tmac ".
See the items below for further details.
...
* GNU troff now strips a leading neutral double quote from the argument
to the `cf`, `hpf`, `hpfa`, `mso`, `msoquiet`, `nx`, `pi`, `pso`,
`so`, `soquiet`, `sy`, and `trf` requests, and the second argument to
the `open` and `opena` requests, allowing it to contain embedded
leading spaces.
* GNU troff now accepts space characters in the argument to the `cf`,
`hpf`, `hpfa`, `mso`, `msoquiet`, `nx`, `so`, `soquiet`, and `trf`
requests, and the second argument to the `open` and `opena` requests.
See "soelim" below.
...
* soelim no longer requires embedded space characters in `so` arguments
to be backslash-escaped. (It continues to support that syntax, even
though neither AT&T nor GNU troff ever has.) If the argument to a
`so` request must contain leading spaces, any such sequence of spaces
must now be prefixed with a double quote character ("), which the
program then discards. These changes are to better align this
program's parsing rules with the language of the formatter; consider
the `ds` and `as` requests.
[2]
5.1.7 Requests and Macros
-------------------------
...
GNU 'troff''s requests and escape sequences comprise the control
language of the formatter. Of key importance are the requests that
define macros. Macros are invoked like requests, enabling the request
repertoire to be extended or overridden.(3) (*note Requests and
Macros-Footnote-3::)
(3) Argument handling in macros is more flexible but also more
complex. *Note Calling Macros::.
signature.asc
Description: PGP signature
