[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposed: stop subjecting right-hand sides of `char` family requests to
From: |
G. Branden Robinson |
Subject: |
Proposed: stop subjecting right-hand sides of `char` family requests to character translation |
Date: |
Fri, 31 Mar 2023 11:48:45 -0500 |
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
- Proposed: stop subjecting right-hand sides of `char` family requests to character translation,
G. Branden Robinson <=