Or: Should device control commands affect the environment? Recall the definition of the \X escape sequence from CSTR #54 (1992).
10.7. Transparent output. The sequence \X'anything' copies anything
to the output, as a device control function of the form x X anything
(ยง22). Escape sequences in anything are processed.
The foregoing doesn't say anything about copy mode. This has a
brow-raising consequence.
Consider the following input.
$ cat backslash-X-affects-environment.roff
.sp
.tm .f=\n(.f
\X'\fB'
.tm .f=\n(.f
Documenter's Workbench 3.3 troff, Heirloom Doctools troff, and GNU troff
all produce the same output to the standard error stream.
.f=1
.f=3
What they produce as device-independent output might be even more
interesting.
$ DWBHOME=. ./bin/troff backslash-X-affects-environment.roff \
| grep '^x X'
.f=1
.f=3
x X
$ ./bin/troff backslash-X-affects-environment.roff | grep '^x X'
.f=1
.f=3
x X LC_CTYPE en_US.UTF-8
x X
$ ~/groff-stable/bin/groff -Z ./backslash-X-affects-environment.roff \
| grep '^x X'
.f=1
.f=3
x X
Nothing.
So "anything" doesn't exactly make it to the output as a device control,
"transparently" or otherwise. This is because a handful of escape
sequences, like \f, \s, and the GNU extensions \m and \M (which set the
stroke and fill colors, respectively) are never turned into nodes by the
tokenization process; instead, (when not in copy mode) they immediately
alter the current environment.
Another thing to know is that there is no such thing as an environment
in troff's output language. Changes to the environment manifest as one
or more other output commands, like 'f' for font selection, or 's' to
set the type size.
This foregoing exhibits seem like evidence of a design wart to me. On
no *roff do such escape sequences survive to device independent output;
they can't, because they have no (direct) representation there.
I therefore propose to change this, and have the `\X` escape sequence
read its argument in copy mode. That will make it work like the
`device` request in groff 1.23.0 and earlier[1].
Some things this wouldn't change:
1. The ability to interpolate registers and strings inside device
control commands--which I would guess is the main reason "Escape
sequences in anything are processed" as CSTR #54 puts it--remains.
2. The ability to affect the environment "simultaneously" with a device
control command remains possible; just put those escape sequences
_outside_ the device control escape sequence.
So instead of:
\X'ps: \fB\s(12\m[red]big bold red text in my device command\fP'
one would write:
\fB\s(12\m[red]\X'ps: big bold red text in my device command'\fP
...though I am dubious that the former has ever been well-defined
as far as interactions with device operations go.
Thoughts? Objections? Counterexamples?
Regards,
Branden
[1] Earlier this week I pushed a change to make `device` read _its_
argument in interpretation, not copy, mode. My second thoughts
about that are what prompted this proposal.
See <https://savannah.gnu.org/bugs/?64484> for background.
signature.asc
Description: PGP signature
