Re: Possible regression with `groff -C`

[John Gardner]

Wouldn't it be simpler to inline the contents of unicode.tmac? Only two
other macro packages reference it, and the file is arguably short enough
not to violate any DRY principles:

λ GNU-Groff (master): grep -rnw ./tmac -e unicode.tmac
./tmac/html.tmac:546:.mso unicode.tmac
./tmac/tmac.am:62:  tmac/unicode.tmac \
./tmac/tty.tmac:72:.  mso unicode.tmac
./tmac/unicode.tmac:1:.\" unicode.tmac


unicode.tmac has only 3 lines of (relevant) source code:

.char - \[hy]
.char ` \[oq]
.char ' \[cq]



On Sun, 12 Apr 2020 at 13:18, G. Branden Robinson <
address@hidden> wrote:

> At 2020-04-12T12:40:38+1000, John Gardner wrote:
> > > 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.
>
> Aha!  Thanks for taking that glance.  I think I see what needs to be
> done here.  First, what should not be done:
>
> 1. "Just revert the commit."
> 2. Actually comment all this out.
>
> Instead, I think what we need is:
>
> A. To comment this file warning people like me off from trying to
> save/restore .C in the future.  This file is effectively an internal of
> tty.tmac and people should look there for its context.
>
> B. To remove the save/restore.
>
> C. To prefix these .char requests with .do, so they're executed with
> full groff powers even in a compatibility context.
>
> It may seem kind of weird to render a legacy document on a UTF-8
> device, and there may be other barriers to doing so, but this should
> not be one of them.
>
> I'd code this up and write a regression test for it.
>
> Thanks again.
>
> Regards,
> Branden
>