Re: Possible regression with `groff -C`

[John Gardner]

> 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 <
address@hidden> 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 <address@hidden>
> 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
>