Follow-up Comment #2, bug #67734 (group groff): [comment #0 original submission:] > Explicitly unsupport use of these code points in identifiers to clear the way > for bug #40720. (I have no plans to withdraw support for code points 2-7 as > input characters; many legacy documents use them as escape sequence > delimiters.)
More precisely, many legacy documents use *some* of them as escape sequence
delimiters.
As a recent revision of our Texinfo manual and _groff_diff_(7) say...
Delimiters
AT&T troff recognized slightly varying sets of delimiters when
expecting numerical expressions (as with the \h escape sequence),
string expressions (as with the \w escape sequence), and output
comparisons (as in “.if #foo#bar# .tm match”). GNU troff, when not
in compatibility mode, recognizes a single consistent set of
delimiters. Compatibility mode emulates AT&T troff only up to a
point. GNU troff, accepts leaders and tabs as delimiters, as well
as Control+D (EOT or EOF), Control+H (BS or backspace), and
Control+L (FF or form feed), all of which cause AT&T troff to
behave in ways difficult to predict.
(Hmm, I see a stray comma in there.)
Saying "no plans to withdraw support for code points 2, 3, or 5-7" would have
been more precise.
But I also have no plans to withdraw support for code point 4 as an input
character, as unusable as it may be with AT&T _troff_.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67734>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
