Follow-up Comment #9, bug #66481 (group groff): Hi Paul,
At 2024-11-25T15:09:02-0500, Paul Eggert wrote:
> Follow-up Comment #8, bug #66481 (group groff):
>> + case '|':
>> + error("support for '|' as an argument delimiter is deprecated and"
>> + " will be withdrawn in a future release");
>
> A quick survey of what's installed on my desktop suggests that this
> will cause diagnostics to be issued for the man pages for gawk, grep,
> and rcs.
I'm glad to hear it's not *worse*! This bug report has caused me some
disquiet.
> The uses I see are at the top level, so how about if groff issues the
> warning only when \w is nested inside some other quoted construct? I'd
> rather not have to go through those long-working man pages to change
> '|' to some other character. And there should be no problem with \w|X|
> when it's not nested.
As I understand the code, this may be possible--there is a member
function `input_stack::get_level()` that I think would facilitate this.
However, having interpolation-depth-dependent grammar seems almost as
bad to me as having ambiguous grammar.
Here's the solution I'm considering now, having slept on the problem:
1. Go back to accepting `|` for _groff_ 1.24, without diagnostics.
2. We're planning on adding a `-wstyle` option to GNU _troff_ for
_groff_ 1.25 (bug #62776). This can become one. That way people
can run _groff_ 1.25 with that option over corpora of man pages and
see where this problem shows up. I (and fingers crossed, others)
start submitting patches to affected man pages.
3. Stick the above-quoted deprecation message in for _groff_ 1.26.
4. Withdraw support for `|` as a delimiter in _groff_ 1.27 (but see
next paragraph).
Relatedly but distinguishably, it looks to me like I can make GNU
_troff_ *more* AT&T-compatible in compatibility mode (the `-C` option)
by skipping this entire `switch` statement when that mode is enabled.
I'm inclined to make that change adjacently to this one (item 1 above).
While I'm keen to reform *roff grammar in ways that sand down the warts
and sharp edges, I also want GNU _troff_ to render well documents
prepared with AT&T _troff_ in mind, as far as practicable. (I believe I
am following in James Clark's tradition by not, in general, aiming for
bug-compatibility or identical indulgence of undefined behavior.)
> PS. I see that some traditional troff macro libraries in Solaris 10
> /usr/lib/tmac use control-G instead of ', under the theory that user
> strings never contain control-G.
Yes. It was a strategem that was (a) unergonomic, (b) esoteric, and (c)
inadequate to the purpose. If a finite-state automaton could simulate a
pushdown automaton, Chomsky would have told us so.
> I'd hate to have to do that sort of thing.
Fear not--I don't wish to impose that sort of yuckiness on anyone.
Regards,
Branden
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66481>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
