Follow-up Comment #20, bug#63074 (group groff):

Sleeping on the problem provoked illumination, as it sometimes does.

In any other _roff_ context, how would we smuggle something that looks like an
escape sequence into a different interpretation context?

By escaping it.


$ cat
EXPERIMENTS/device-control-request-with-double-escape-special-character-and-partially-collected-line.roff
.device ps: nop \\[u007E]
.br
$ groff -Z
EXPERIMENTS/device-control-request-with-double-escape-special-character-and-partially-collected-line.roff

x T ps
x res 72000 1 1
x init
p1
V12000
H72000
x font 5 TR
f5
s10000
V12000
H72000
md
DFd
x X ps: nop \[u007E]
n12000 0
x trailer
V792000
x stop
$ cat
EXPERIMENTS/device-control-escape-sequence-with-double-escape-special-character.roff
\X'ps: nop \\[u007E]'
$ groff -Z
EXPERIMENTS/device-control-escape-sequence-with-double-escape-special-character.roff
x T ps
x res 72000 1 1
x init
p1
V12000
H72000
x font 5 TR
f5
s10000
V12000
H72000
md
DFd
x X ps: nop \[u007E]
n12000 0
x trailer
V792000
x stop


I get the same output from _groff_ 1.22.4, 1.23.0, and Git HEAD.

This feels like a win.  Needs some discussion in documentation as the
assumption of many users may be "you can't do that".  And to mention the fact
that it's up to the postprocessor to interpret the syntax (and even then
possibly only in the context of a specific device control command).

I'll bolster the unit tests I have pending to make sure this works okay for
all output devices.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63074>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/


Reply via email to