Follow-up Comment #7, bug #67372 (group groff): [comment #5 comment #5:] > I think three tasks arise from this exploration. > > 1. I should document that if one wants AT&T-compatible treatment of > interpolated delimiters, one should use compatibility mode. The > language of our documentation should be broadened: _groff_'s concept > of "input level" (or "interpolation depth" as I prefer to term it) > applies not just to the _arguments_ of a delimited escape sequence, > _but to the delimiters themselves_. [...] > 3. I should add test cases that force me to nail down the formatter's > behavior when using string interpolations to construct escape > sequences.
I should add that I am concerned that it's impossible to intelligently and
coherently maintain the concept of "interpolation depth" (or "input level")
when the parser state has encountered the escape function selector and is
expecting a delimiter. Interpolating the delimiter with a `\*` interpolation
necessarily implies performing an interpolation and therefore increasing the
depth, which defeats the whole purpose of having an interpolation depth in the
first place.
Our manual describes why it exists.
Delimiter syntax is complex and flexible primarily for historical
reasons; the foregoing restrictions need be kept in mind mainly when
using 'groff' in AT&T compatibility mode. GNU 'troff' keeps track of
the nesting depth of escape sequence interpolations, so the only
characters you need to avoid using as delimiters are those that appear
in the arguments you input, not any that result from interpolation.
Typically, ''' works fine. *Note Implementation Differences::.
$ groff -T ps
.de Mw
. nr wd \w'\\$1'
. tm "\\$1" is \\n(wd units wide.
..
.Mw Wet'suwet'en
.Mw Wet+200i
.cp 1 \" turn on compatibility mode
.Mw Wet'suwet'en
.Mw Wet'
.Mw Wet+200i
error-> "Wet'suwet'en" is 54740 units wide.
error-> "Wet'+200i" is 42610 units wide.
error-> "Wet'suwet'en" is 15860 units wide.
error-> "Wet'" is 15860 units wide.
error-> "Wet'+200i" is 14415860 units wide.
We see here that in compatibility mode, the part of the argument
after the ''' delimiter escapes from its context and, if nefariously
crafted, influences the computation of the WD register's value in a
surprising way.
(I see I used the nonce phrase "nesting depth" above. I should change it to
"interpolation depth".)
(Also Texinfo is kind of lame, and quotes the single-quote character
with...single quotes. :-| )
Whatever one calls the concept, it's a James Clark innovation to the *roff
language (or maybe an _sqtroff_ idea that he reimplemented), and I think it is
a good one.
It may therefore be necessary to "ban" string interpolations when the
formatter expects an opening delimiter on the input stream.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67372>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
