[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 #62776] [troff] want "style" warning category for self-deceptive inputs

Follow-up Comment #22, bug #62776 (group groff): Warn on: Use of delimiter characters that are invalid to delimit a _numeric expression_ in a context where a general argument is accepted. The user should have to keep only one set of valid delimiters in mind, and switcheroo games with a variety o

[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

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 #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

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

[bug #66479] [PATCH] failing tests on macos on HEAD (2562cf237)

Follow-up Comment #2, bug #66479 (group groff): Hi Branden! Here you are: ../src/roff/groff/tests/dvi-device-smoke-test.sh checking 'groff -Kutf8 -Tdvi -Z' checking 'groff -Kutf8 -Tdvi' 000f7 02 00 03 e0 30 00 00 e1 d8 00 00 03 e8 00 8b 02000 00 00 01 00 00 0

[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 #66479] [PATCH] failing tests on macos on HEAD (2562cf237)

Follow-up Comment #1, bug #66479 (group groff): At 2024-11-23T11:00:03-0500, Sven Schober wrote: > Date: Sat 23 Nov 2024 03:59:59 PM UTC By: Sven Schober > It's me again, your (hopefully) friendly macos build tester. :) > > Today, and on the latest HEAD (2562cf237), I found 5 failing tests on > m

[bug #66480] [mom] remove trailing spaces in the source files in the mom package

Follow-up Comment #4, bug #66480 (group groff): "git" has a "tool" to point out whitespace, see for example "git-apply(1)" and git-config(1)". ___ Reply to this item at: ___

[bug #65099] 1.24.0 release goals

Update of bug #65099 (group groff): Depends on: => bugs #66481 ___ Reply to this item at: ___ Message sent via Sav

[bug #66481] \w|x| no longer works in bleeding-edge groff

Update of bug #66481 (group groff): Status:None => Confirmed Assigned to:None => gbranden ___ Follow-up Comment #2: ...and in DWB nroff as well (from which Heirloom app

[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: