Proposed: stop subjecting right-hand sides of `char` family requests to character translation

[G. Branden Robinson]

Dave Kemper and I believe that the right-hand sides of groff character
definitions with the `char` request and its siblings (`fchar`, `fschar`,
`schar`) should no longer be subject to `tr` character translation.

See https://savannah.gnu.org/bugs/?55155 for background.

1.  It seems unlikely that anyone relies on doing this.
2.  Heirloom troff, nominally compatible with groff extensions, ends up
    in a confused state if you try it there.
3.  neatroff faithfully reproduces groff behavior here, so it would be
    good to get Ali Gholami Rudi's opinion of this change.
4.  mandoc(1) appears to ignore `char` requests.
5.  Doing this would enable a clearer separation of responsibilities
    between `tr` and `char`; namely, it would enable character
    translations with `tr` to become part of the formatter's
    environment, which is motivated by
    <https://savannah.gnu.org/bugs/?62691>.

The idea here is that `tr`'s purpose is to permute the groff character
set, the union of the set of ordinary characters (U+0021..U+007E) and a
user-extensible set of special characters, whereas the purpose of the
`char` family is to manipulate the members of the set of special
characters.  (You can try `.rchar a`, but it silently fails.)

Thoughts?

Regards,
Branden

signature.asc
Description: PGP signature