Follow-up Comment #6, bug #66686 (group groff): At 2025-01-29T03:38:30-0500, Dave wrote: > Follow-up Comment #5, bug #66686 (group groff): > > This fix did the trick. Thanks! > > My only quibble (and you knew I'd have one) is with the wording of the > warning.
;-)
> $ echo "Length of 'abc': \w+abc+u" | groff -Tascii -ww | cat -s
> troff:<standard input>:1: warning: interpreting character '+' as an escape
> sequence delimiter; it is ambiguous because it is also meaningful in a
> numeric
> expression
> Length of 'abc': 72u
> For the \w escape in particular, there's no ambiguity with an
> arithmetic + because the delimited expression is not numeric (and
> comment #2 points out that there's no ambiguity even if a \w
> expression is part of a larger calculation). But it appears this
> warning is generic to any escape that encounters a + delimiter, and if
> that's the case, retaining this wording is probably more robust than
> special-casing the \w delimiter.
In fact there's "no ambiguity" with _most_ of the delimited escape
sequences--`\B` being a glaring exception. But, because most or all of
these escape sequences can be be embedded in larger expressions that
_can_ be numeric, that's why I went with the wording I did and made it
parallel across all sites where it occurs.
.nr a \w+foobar++2n
...is precisely the sort of case I had in mind while writing.
From my high horse, I proclaim that there's no reason in _groff_ to
craft such "clever" expressions, because GNU troff keeps track of the
interpolation depth (a.k.a. "input level").
In AT&T compatibility mode, different tradeoffs were made historically,
and so I have the former accept such perversities without comment.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66686>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
