Follow-up Comment #8, bug #55155 (project groff):
Unfortunately for me, my mental model in comment #7 does not accurately
describe groff's behavior.
$ cat ATTIC/zz_top.groff
.tr zx
.char \(zz zeezee
\(zz top
.pl \n(nlu
$ nroff ATTIC/zz_top.groff
xeexee top
You did warn me:
> The manual explicitly says a glyph defined by .char can be the source or
target of a .tr
...that much is okay...
> and that .char itself is nonrecursive,
...as is this...
> but this particular interaction does not seem to be directly addressed.
...which leads directly to the summary of this ticket.
I would therefore propose changing this behavior, such that `tr` does _not_
apply to the RHS of `char` character definitions.
If you agree, then we should shop this change to the groff list to see if it
draws protest from anyone relying on this behavior.
People might not even know they're relying on this; if it's practical, it
might help to add a diagnostic warning of a character appearing in a `char`
family RHS also occurring as a...transliterand.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?55155>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
