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 < [email protected]> 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 >
