[bug #64559] [troff] does not diagnose trailing garbage in register assignment

Update of bug #64559 (group groff): Status:None => Duplicate Assigned to:None => gbranden Open/Closed:Open => Closed __

[bug #64240] [troff] make numeric expression parser more sensitive to nonsense

Follow-up Comment #3, bug #64240 (group groff): Closed bug #64559 as a duplicate of this. And we really, really, should be raising a diagnostic here, because... $ nroff -ww > /dev/null .nr a 1 2 \n+a .tm a=\na a=3 .nr b 1g 2 \n+b .tm b=\nb b=1 .ex DWB and Heirloom Doctools _troff_s behave the

[bug #66085] second run of "make" requires user interaction

Update of bug #66085 (group groff): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #6: [comment #5 comment #5:

[bug #66085] second run of "make" requires user interaction

Follow-up Comment #7, bug #66085 (group groff): [comment #6 comment #6:] > So the Makefile is using $HOME/bin/mv rather than the system's mv to move files. This still feels mildly buggy, I'm not sure I agree--why _shouldn't_ a build use $PATH to resolve command names? Historically, this is wha

[bug #64240] [troff] make numeric expression parser more sensitive to nonsense

Update of bug #64240 (group groff): Status:None => In Progress Assigned to:None => gbranden ___ Follow-up Comment #4: I must know the formatt

[bug #66085] second run of "make" requires user interaction

Follow-up Comment #8, bug #66085 (group groff): [comment #7 comment #7:] > why _shouldn't_ a build use $PATH to resolve command names? Because essential system commands live in predictable places and are the most likely to do what's intended. An aberrant path might not even include /bin at all,

[bug #64240] [troff] make numeric expression parser more sensitive to nonsense

Follow-up Comment #5, bug #64240 (group groff): $ cat EXPERIMENTS/misleading-units.roff .nr a 5in .nr b 3cm .nr c 9pt+3vee .nr d 5i3c9p $ ./build/test-groff -ww -T ascii EXPERIMENTS/misleading-units.roff troff:EXPERIMENTS/misleading-units.roff:1: warning: expected end of line or an auto-incremen

[bug #63202] [troff] missing delimiter diagnostics could say what they were expecting

Update of bug #63202 (group groff): Status:None => In Progress Assigned to:None => gbranden ___ Follow-up Comment #1: Almost 2 years later, t

[bug #63202] [troff] missing delimiter diagnostics could say what they were expecting

Follow-up Comment #2, bug #63202 (group groff): $ cat ATTIC/mismatched-delimiter-demo.groff foo\R'a 20g' foo\L'1ig# foo\h'5mbar foo\H'20@ $ ./build/test-groff -ww -z ATTIC/mismatched-delimiter-demo.grofftroff:ATTIC/mismatched-delimiter-demo.groff:1: warning: D closing delimiter does not match; e

[bug #63587] [troff] set .R register to maximum representable integer

Update of bug #63587 (group groff): Status:None => In Progress Assigned to:None => gbranden ___ Reply to this item at: