Update of bug #55155 (project groff):
Assigned to: barx => gbranden
_______________________________________________________
Follow-up Comment #10:
[comment #9 comment #9:]
> [comment #8 comment #8:]
> > I would therefore propose changing this behavior, such that `tr`
> > does _not_ apply to the RHS of `char` character definitions.
>
> I do feel like this is more in line with this sentence from the info manual:
"the first argument of 'tr' should be an input character or entity, and the
second one a glyph entity." (These words remain unchanged since being added
in 2002, [http://git.savannah.gnu.org/cgit/groff.git/commit/?id=21260e1c
commit 21260e1c].) Although the docs are not explicit about this, I think
intuitively the RHS of a .char definition wouldn't be considered "an input
character or entity."
Agreed.
> > 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.
>
> Yeah, some groffers do exploit obscure behavior. On the plus side, .char
and its family originate with groff (though at least Heirloom also implements
them),
Yeah. WRONGLY. (I mean groff-incompatibly in this case, but that's a good
thing, as it increases our latitude for just fixing this.)
$ cat ATTIC/zz_top.groff
.tr zx
.char \(zz zeezee
\(zz top
.pl \n(nlu
$ ~/heirloom/bin/nroff ATTIC/zz_top.groff | cat -s
top
As you can perhaps see, this input also screwed up Heirloom troff's ability to
interpret the (portable!) `pl` request. Something to do with having the input
line undergo character translation, expansion of a character definition, or
both, confused it.
> so we don't have to worry about deviating from AT&T.
Reassigning to self and keeping in "Need Info" status while I take this to the
list.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?55155>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
