On Tuesday, 16 January 2024 19:22:48 GMT G. Branden Robinson wrote: > Or: Should device control commands affect the environment? > ...
> 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]. This is not what I am seeing in current 'master/head'. Using this as a test:- =============================================== .ds abc def .br black \X'abc=\*[abc]\m[red]\(em\[u0431]' red?\m[black] .device device abc=\*[abc]\m[red]\(em\[u0431] red? =============================================== With 1.23.0 it produces:- x T ps x res 72000 1 1 x init p1 x font 5 TR f5 s10000 V12000 H72000 md DFd tblack wh2500 V12000 H96160 mr 65535 0 0 x X abc=def wh2500 tred? wh5000 V12000 H120870 mr 0 0 0 x X device abc=def\m[red]\(em\[u0431] tred? n12000 0 x trailer V792000 x stop And the colour sequence of the words goes - black red black. You can also see the unicode character \[u0431] has been successfully passed to the postprocessor when using .device and also the \m[red] has not "leaked" into the text output stream but just passed to the postprocessor. The \X variant cleaned all the nodes before passing on what is left (and leaked red). Now on current master which contains the changes on which you are asking us to comment, this is the result:- x T ps x res 72000 1 1 x init p1 troff:X.trf:4: error: special character 'em' is invalid within a device control command troff:X.trf:4: error: special character 'u0431' is invalid within a device control command troff:X.trf:6: error: special character 'em' is invalid within a device control command troff:X.trf:6: error: special character 'u0431' is invalid within a device control command x font 5 TR f5 s10000 V12000 H72000 md DFd tblack wh2500 V12000 H96160 mr 65535 0 0 x X abc=def wh2500 tred? wh5000 V12000 H120870 x X device abc=def tred? n12000 0 x trailer V792000 x stop Now we can see that both \X and .device are behaving the same way as \X used to (with the addition of a new error to document the facility to pass unicode characters, and others, has been withdrawn). Plus, both methods are now a leaky red! You appear to have achieved the exact opposite of what you set out to achieve - "make it (\X) work like the device request in 1.23.0 and earlier". I think your instincts are correct, once you have completed your for loop the removal of unwanted nodes from a string will be simple, so it would not be necessary to rely on \X doing it for you. The device request currently operates as \X is documented in CSTR #54 so it makes sense to have our \X behave the same. Usually it is better to preserve data rather than arbitrarily discard it so that it can't be recovered, so I agree with your desire to make \X behave like .device has always behaved, but possibly after your "for" request is ready so people have a simple way of choosing the current behaviour, i.e. removing nodes from a string or passing the string as a whole. In https://savannah.gnu.org/bugs/?63074 which is titled "develop convention for encoding Unicode character sequences for passage to device control commands" shows you understand the necessity of having the ability to pass all unicode and other characters to postprocessors and are aware that .device was already capable of doing that, I have no objection to you extending this capability to \X if that is your wont, but the current state of master is the opposite. Cheers Deri
