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/