> Any lurking experts have any suggestions? >From a glance, it looks like the `.C` register is being set twice: once by the calling tty.tmac, and again by unicode.tmac. If I comment out a few lines in the latter:
.\" unicode.tmac .\" .\" .nr _C \n(.C .cp 0 .char - \[hy] .char ` \[oq] .char ' \[cq] .\" .cp \n[_C] ... it suddenly works. On Sun, 12 Apr 2020 at 11:52, G. Branden Robinson < [email protected]> wrote: > At 2020-04-12T11:12:32+1000, John Gardner wrote: > > After building Groff from master, I noticed one of Roff.js's regression > > tests failed when asserting compatibility mode: > > > > *Command:* > > printf '.ds FOO BAR\n\\*[FOO]' | groff -C -Tutf8 | head -n1 > > > > > > *Expected output:* > > FOO] > > > > *Actual output:* > > BAR > > > > > > This only started happening since I installed a freshly-built Groff with > > the latest changes. Groff 1.22.4 (and earlier) don't have this problem. > > I've never had a bisection go so smoothly. > > Of course this breakage was my fault (a statistical likelihood). > > d322f1951dcfc6ac7816fe8a654731041533443c is the first bad commit > commit d322f1951dcfc6ac7816fe8a654731041533443c > Author: G. Branden Robinson <[email protected]> > Date: Fri Jun 28 01:37:44 2019 +1000 > > tmac/unicode.tmac: Execute in compatibility mode. > > ...since the script uses a GNU extension (.char). > > Also update editor hints to Vim and (modern) Emacs. > > :100644 100644 8e7973b62998f3db237618ed01ec9f3882fa83f9 > be9d68f2fde2d2f1a7551b81deb5ac0082f0e724 M ChangeLog > :040000 040000 5b2239b52ef1d282f42800338a687eb6036a21b5 > 31458639171a78e96a10d24cff5498956a7bab3b M tmac > > That description is ass-backwards. What I did was add a line turning > compatibility mode OFF (.cp 0). (The ChangeLog was already fixed some > time ago.) > > But .char _is_ a groff extension, so, hmm. > > diff --git a/tmac/unicode.tmac b/tmac/unicode.tmac > index 89864a6b..5bda095b 100644 > --- a/tmac/unicode.tmac > +++ b/tmac/unicode.tmac > @@ -1,8 +1,14 @@ > -.\" -*- nroff -*- > -.\" > .\" unicode.tmac > .\" > +.nr _C \n(.C > +.cp 0 > .char - \[hy] > .char ` \[oq] > .char ' \[cq] > -.\" EOF > +.cp \n[_C] > +.\" > +.\" Local Variables: > +.\" mode: nroff > +.\" fill-column: 72 > +.\" End: > +.\" vim: set filetype=groff textwidth=72: > > The following experiment on HEAD confirms the smoking gun: > > $ printf '.ds FOO BAR\n\\*[FOO]' | ./build/test-groff -C -Tascii | head -n1 > troff: <standard input>:2: warning: macro '[' not defined > FOO] > > ...since unicode.tmac doesn't get read if the output device is "ascii": > > $ grep -C 1 utf8 tmac/tty.tmac > . > .if !'\*[.T]'utf8' \{\ > . ie c\[pc] \ > -- > . > .if '\*[.T]'utf8' \ > . mso unicode.tmac > > Note that the entire contents of unicode.tmac appear in the diff above. > I do not even begin to have a theory as to what's going on here. > > Any lurking experts have any suggestions? > > Regards, > Branden >
