[bug #55155] [troff] .tr is applied to the RHS of .char definitions

[G. Branden Robinson]

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/