Hi Branden,
[re-arranging]
On Sat Feb 22, 2025 at 9:37 PM CET, G. Branden Robinson wrote:
> At 2025-02-22T16:38:00+0100, onf wrote:
> [...]
> > I feel like changing ab, hpf, hpfa, nx, so, and tm (the others aren't
> > implemented by neatroff) to allow spaces in the middle of their
> > arguments might have more chance of success.
>
> I begin to get the feeling you're not paying close attention to what I'm
> saying in emails, what I've quoted from the "NEWS" file,[1] or how GNU
> troff actually behaves.
I felt the same way about you, but it seems I might just be
misunderstanding your words.
I have in fact read the NEWS item, which says:
VERSION next
============
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
To me, this pretty clearly says that this:
$ echo '.ab DONE' > nx
$ nroff << EOF
.nx nx \" continue with file nx
EOF
will no longer work.
Testing with git master though, it does work.
$ git describe
1.23.0-2819-g0d8867598
$ ./nroff << EOF
.nx nx \" continue with file nx
EOF
DONE
But that's probably because it doesn't contain these changes yet:
$ echo '.ab DONE' > 'foo bar'
$ cat 'foo bar'
.ab DONE
$ ./nroff << EOF
.nx foo bar \" skip to next file
EOF
troff:<standard input>:1: error: can't open 'foo': No such file or directory
Which is weird because git log claims it does:
$ git log --pretty=reference | grep spacey | grep -w nx
4812e5548 ([troff]: `nx` now accepts spacey file names., 2024-12-07)
And just to be sure...
$ make
make all-recursive
make[1]: Entering directory '/home/ondra/Downloads/git/groff'
make[2]: Entering directory '/home/ondra/Downloads/git/groff'
make[2]: Leaving directory '/home/ondra/Downloads/git/groff'
make[1]: Leaving directory '/home/ondra/Downloads/git/groff'
(That is, all targets are up to date.)
> I encourage you to examine the behavior of AT&T troff with respect to
> the `ab`, `nx`, `so`, and `tm` requests. I have pointed you several
> times to the comments in Savannah #65108,[2] to apparently little avail.
> > I forgot to emphasize the likely largest obstacle, which is the fact
> > that it
>
> (presumably Savannah #66625, and/or changes already in Git)
No, Savannah #65108.
> > would break compatibility with documents written for neatroff.
>
> In what way?
Reading the ticket #65108, comment #3 says:
1. An argument of type `file` (as described in groff(7)) to a request
consumes the rest of the rest [sic] of the line.
2. Unescaped spaces can therefore populate the argument.
3. A leading double quote is recognized and removed; a file name can
thus start with spaces.
4. Any other/remaining double quotes are not treated specially.
5. Only the following escape sequences are recognized.
5a. `\ ` (backslash-space) represents a space. It is not necessary
in troff, but is recognized to avoid disrupting existing soelim(1)
usage.
5b. `\"` ends the file name argument and starts a comment.
5c. `\\` represents a (single) literal backslash. It is handled
however the system's standard C library wants to handle it.
5d. `\[u00XX]` where each X is an uppercase hexadecimal digit encodes
a character. Only codes in the range 00-1F and 80-FF are accepted
in this syntax; those in the range 20-7F are ignored with a
diagnostic advising the user to deobfuscate their inputs.
The combination of points 1, 5, and 5b seems to imply that
.nx nx \" load file nx
will be interpretted as loading file 'nx ' (without the quotes).
That would obviously break compatibility, because other troffs
interpret it as loading file 'nx':
$ 9 nroff << EOF
.nx nx \" load file nx
EOF
DONE
> > Ali seems averse to breaking backwards compatibility with both AT&T
> > troff and past versions of neatroff.
>
> That's a reasonable inclination. I think a more accurate
> characterization of the changes I have made and am proposing, however,
> is that things that simply never could work before, now can.
If that's an accurate characterization, then please explain what that
NEWS file is about, because I don't get it.
> Here are exhibits of GNU troff behavior from 1.22.3 and Git HEAD when
> encountering spaces in the middle of arguments to the requests you name.
>
> [...]
>
> How does any of the above illustrate a break of compatibility with AT&T
> troff, or with neatroff?
It doesn't, because there is not a single line containing a comment
separated from the argument by a space. Read the examples I gave above.
Thanks,
onf
