[bug #66931] [tbl] writes line number "1" in every `lf` request since commit 25ef9f6bda

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

[bug #66977] [troff] unfilled lines should provoke warnings if overset

Update of bug #66977 (group groff): Summary: [troff]: unfilled lines should provoke warnings if overset => [troff] unfilled lines should provoke warnings if overset ___ Reply to this item at:

[bug #66932] [troff] assertion failure when attempting to format gzipped input

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

[bug #66932] [troff] assertion failure when attempting to format gzipped input

Follow-up Comment #3, bug #66932 (group groff): At 2025-03-20T20:31:18-0400, Dave wrote: > Follow-up Comment #2, bug #66932 (group groff): > > I can get it even smaller: I get the assertion failure using git head > even with the "C-" removed from the input. Aha! Excellent. Yeah, once I got as f

[bug #66977] [troff]: unfilled lines should provoke warnings if overset

Update of bug #66977 (group groff): Summary: [troff]: unfilled llines should provoke warnings if overset => [troff]: unfilled lines should provoke warnings if overset ___ Follow-up Comment #2: Thanks, Dave. I have no plan

[bug #66919] [troff] behavior change in some .hcode calls when a special character is the first argument

Follow-up Comment #28, bug #66919 (group groff): Also, this older remark has bearing on my last comment. [comment #19 comment #19:] > But generally in language development, if you break someone's > reliance on undefined behavior, you don't owe them an apology > and possibly not even notice. Tru

[bug #62692] [eqn] want a way to recover "set" parametric defaults

Update of bug #62692 (group groff): Summary: [eqn] want a way to recover "set" parameteric defaults => [eqn] want a way to recover "set" parametric defaults ___ Reply to this item at:

[bug #66932] CJK

Update of bug #66932 (group groff): Summary: [troff] assertion failure when attempting to format gzipped input => CJK ___ Reply to this item at: __

[bug #66919] [troff] .hcode sometimes fails to accept a special character as a first argument

Follow-up Comment #9, bug #66919 (group groff): Okay, then, we need to burn this down to first principles, because you are blinding me with your claims that the `hcode` request is **ever** "failing to accept a special character as a first argument". As far as I can tell, it is doing so with perfe

[bug #66919] [troff] .hcode sometimes fails to accept a special character as a first argument

Follow-up Comment #10, bug #66919 (group groff): Not trying to be difficult. What I'm trying to get at is that the comment #4 test file shows observable output changing from all prior groffs I have in my grasp (which span nearly 20 years). You confirmed this output change but ascribed it to a ch

[bug #44018] [PATCH] gtroff hangs in environment::possibly_break_line with -mja

Follow-up Comment #8, bug #44018 (group groff): commit cdcb5c244a33abe12f7c544620afe0a5906fd20a Author: G. Branden Robinson Date: Thu Apr 3 21:54:44 2025 -0500 [groff]: Improve CJK break/adjustment test case. * src/roff/groff/tests/do-not-loop-infinitely-when-breaking-cjk.sh: Mak

[bug #66931] [tbl] regression: too many '.lf 1 ...' lines

URL: Summary: [tbl] regression: too many '.lf 1 ...' lines Group: GNU roff Submitter: bjarniig Submitted: Thu 20 Mar 2025 03:32:25 AM UTC Category: Preprocessor tbl

[bug #63354] [PATCH] [tmac]: refine fallbacks.tmac

Follow-up Comment #46, bug #63354 (group groff): [comment #30 comment #30:] > But this won't work in an .fchar, whose RHS is evaluated upon > definition rather than interpolation. I was flat-out wrong about this. However: > But even then, there are other potential pitfalls to consider. These o