[bug #66481] [troff] `\w|x|` no longer works on the bleeding edge of Git

Follow-up Comment #11, bug #66481 (group groff): commit 39c1176bfa9ba84d519b015b1453f316e013d1de Author: G. Branden Robinson Date: Mon Jan 27 18:52:39 2025 -0600 [troff]: Fix Savannah #66686 (`\w|foo|` blues). * src/roff/troff/input.cpp (is_char_usable_as_delimiter): Restore `|`

[bug #66481] [troff] `\w|x|` no longer works on the bleeding edge of Git

Update of bug #66481 (group groff): Status: In Progress => Fixed Open/Closed:Open => Closed Planned Release:None => 1.24.0 ___ Follow-up Comment #10

[bug #66481] [troff] `\w|x|` no longer works on the bleeding edge of Git

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 releas

[bug #66481] [troff] `\w|x|` no longer works on the bleeding edge of Git

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

[bug #66481] [troff] `\w|x|` no longer works on the bleeding edge of Git

Follow-up Comment #7, bug #66481 (group groff): [comment #6 comment #6:] > In "fallbacks.tmac" we have the following. > > . fchar \[u2012] \^\v'-.3m'\l'\w"\0"u'\v'+.3m'\^\" figure dash Bug #63354 proposes to overhaul this definition. (which I note for completeness, not because it affects you

[bug #66481] [troff] `\w|x|` no longer works on the bleeding edge of Git

Follow-up Comment #6, bug #66481 (group groff): My concern is a real-world one, and _groff_ itself trips over it. Exhibit: In "fallbacks.tmac" we have the following. . fchar \[u2012] \^\v'-.3m'\l'\w"\0"u'\v'+.3m'\^\" figure dash That's a "general argument" (`\w`) inside a (partially) "numer

[bug #66481] [troff] `\w|x|` no longer works on the bleeding edge of Git

Follow-up Comment #5, bug #66481 (group groff): Ugh. Because escape sequences can be nested, to fix this I have to track more state in the formatter: whether the current input level is "general" or "numeric". It would be nice if we could wean people off of using "|" as a delimiter just as we did

[bug #66481] [troff] `\w|x|` no longer works on the bleeding edge of Git

Update of bug #66481 (group groff): Status: Confirmed => In Progress ___ Reply to this item at: ___ Message sent via Sav

[bug #66481] [troff] `\w|x|` no longer works on the bleeding edge of Git

Follow-up Comment #4, bug #66481 (group groff): [comment #3 comment #3:] > $ printf '\\l95n\\&*9\n' | ~/groff-1.22.3/bin/nroff | cat -s > :1: cannot use character `9' as a starting delimiter > 5n*9 > > If I had to wager, I'd bet that the foregoing input has been > rejected by GNU _troff_ since

[bug #66481] [troff] `\w|x|` no longer works on the bleeding edge of Git

Follow-up Comment #3, bug #66481 (group groff): I can fix this but GNU _troff_ is still going to be stricter than AT&T _troff_, albeit not with respect to the `\w` escape sequence, which accepts what we might call a "general" argument rather than a numeric expression argument. Consider use of the

[bug #66481] [troff] `\w|x|` no longer works on the bleeding edge of Git

Update of bug #66481 (group groff): Summary: \w|x| no longer works in bleeding-edge groff => [troff] `\w|x|` no longer works on the bleeding edge of Git ___ Reply to this item at: