Follow-up Comment #6, bug #55154 (project groff):
I may be groping toward an apology (in the formal, rhetorical, not
conversational, sense) in the course of recent plus pending changes to
groff_diff(7).
I had forgotten, and thus was semi-surprised, that ".tr a\ " (note trailing
space) was not accepted.
But that surprise was only semi- because as James Clark pointed out, ".tr a",
more often seen as ".tr ~" is a truly bizarre feature.
I _suspect_ this feature crept in very early, before the "\ " escape sequence,
which gets you the same result without having to bother with a translation.
Clark stayed precisely within this non-orthogonality when supporting ".tr
a\~".
Possibly, we should try deprecating both of these uses of `tr`, so that we can
say simply that `tr` remaps *characters* (ordinary or special). Full stop.
I don't think \| and \^ are too much of a challenge here. They're still not
_characters_, and we could introduce new directives to the font description
file syntax to replace them.
hair-space-width 10
thin-space-width 20
I observe that the "\| and \^ in the font description file" trick is _not_
documented or implied in CSTR #54, though it does appear in CSTR #97. Perhaps
by 1992, Kernighan began to think better of it.
Anyway, here's what is in my working copy.
> In GNU troff, the tr request can map characters to the unbreakable
> space escape sequence \~ as a special case (tr normally operates
> only on characters). This feature replaces the odd-parity tr
> mapping trick used in AT&T troff documents, where a character, often
> ~, was "sacrificed" by mapping it to "nothing", drafting it into use
> as an unadjustable, unbreakable space. (This feature was gratuitous
> even in early AT&T troff, which supported the \space escape sequence
> by 1976.) Often, it makes more sense to use GNU troff's \~ escape
> sequence instead, which has been adopted by every other active troff
> implementation except that of Illumos, as well as by the non-troff
> mandoc. Translation of a character to \~ is unnecessary.
Thoughts?
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?55154>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
