[bug #66040] [troff] no longer warns about unrecognized .hcode input

Follow-up Comment #5, bug #66040 (group groff): [comment #4 comment #4:] >error("second member of hyphenation code pair must be an" > " ordinary character, or a special character already" > " assigned a hyphenation code"); This message's problem isn't that it's long--it migh

[bug #66040] [troff] no longer warns about unrecognized .hcode input

Follow-up Comment #6, bug #66040 (group groff): [comment #5 comment #5:] > [comment #4 comment #4:] > >error("second member of hyphenation code pair must be an" > > " ordinary character, or a special character already" > > " assigned a hyphenation code"); > > This message's

[bug #66040] [troff] no longer warns about unrecognized .hcode input

Follow-up Comment #7, bug #66040 (group groff): On second thought, it feels more orthogonal to go ahead and copy an uninitialized (zero) value from the second member of a hyphenation code pair. And that would also solve the "problem" noted in a "TODO" commend of permitting the removal of a value

[bug #66040] [troff] no longer warns about unrecognized .hcode input

Follow-up Comment #8, bug #66040 (group groff): [comment #6 comment #6:] > [comment #5 comment #5:] > > The special character \['e] in the second line is still > > rejected even after being assigned a code in the first. > > I noticed that too. I think it's a bug. I'm working on it. I mean, sur

[bug #66038] [troff] want "invalid line length" diagnostic to not misrepresent user input

Update of bug #66038 (group groff): Summary: [troff] want "invalid line length" diagnostic to quote user input => [troff] want "invalid line length" diagnostic to not misrepresent user input ___ Reply to this item at: <

[bug #66038] [troff] want "invalid line length" diagnostic to not misrepresent user input

Update of bug #66038 (group groff): Status: Postponed => Need Info Assigned to:gbranden => barx ___ Follow-up Comment #4: How about "computed li

[bug #66040] [troff] no longer warns about unrecognized .hcode input

Follow-up Comment #9, bug #66040 (group groff): [comment #8 comment #8:] > [comment #6 comment #6:] > > [comment #5 comment #5:] > > > The special character \['e] in the second line is still > > > rejected even after being assigned a code in the first. > > > > I noticed that too. I think it's a

[bug #66040] [troff] no longer warns about unrecognized .hcode input

Follow-up Comment #10, bug #66040 (group groff): I said: > Accented vowels are members of those equivalence classes in GNU troff That's actually not true. In German, they're _all_ _sui generis_ except for the uppercase versions. .hcode ä ä â â à à á á ã ã å å æ æ .hcode ç ç .hcode é é

[bug #66038] [troff] want "invalid line length" diagnostic to not misrepresent user input

Follow-up Comment #5, bug #66038 (group groff): That seems a much more succinct way to phrase my second suggestion! ___ Reply to this item at: ___ Messa

[bug #66038] [troff] want "invalid line length" diagnostic to not misrepresent user input

Update of bug #66038 (group groff): Status: Need Info => In Progress Assigned to:barx => gbranden ___ Follow-up Comment #6: Cool--I'll proceed with

[bug #65225] [tbl] character repetitions in cells broken (\Rx)

Update of bug #65225 (group groff): Item Group: Rendering/Cosmetics => Incorrect behaviour ___ Reply to this item at: ___ Message

[bug #65980] [troff] diagnose why directory operands can't be opened

Update of bug #65980 (group groff): Severity: 2 - Minor => 1 - Wish ___ Reply to this item at: ___ Message

[bug #65977] [troff] `device` request should work early as `\X` does

Update of bug #65977 (group groff): Item Group: Warning/Suspicious behaviour => Incorrect behaviour ___ Reply to this item at: ___ Mes

[bug #62040] [troff] crash at formatter exit due to MTSM stack cleanup

Update of bug #62040 (group groff): Planned Release: 1.24.0 => None ___ Follow-up Comment #18: Unsetting "Planned Release" field so this duplicate doesn't show up in queries of bugs fixed by _gr

[bug #66040] [troff] no longer warns about unrecognized .hcode input

Follow-up Comment #11, bug #66040 (group groff): Fuller reply later, when I've had time to digest all this, but to get the ball rolling: [comment #10 comment #10:] > What I gather is that what bug #42870, and you, are asking for > is that we be able to substitute special characters for these > or

[bug #66040] [troff] no longer warns about unrecognized .hcode input

Update of bug #66040 (group groff): Status: In Progress => Fixed Open/Closed:Open => Closed Planned Release:None => 1.24.0 __

[bug #66038] [troff] want "invalid line length" diagnostic to not misrepresent user input

Update of bug #66038 (group groff): Status: In Progress => Fixed Open/Closed:Open => Closed Planned Release:None => 1.24.0 __

[bug #63176] [me] After column-count changes, -me might place running text on page below footnote

Update of bug #63176 (group groff): Status: Need Info => Confirmed ___ Follow-up Comment #8: [comment #7 comment #7:] > Here's a proposed patch. Applied, I see, in [http://git.savannah.gnu.org

[bug #66033] [devps] support "maintainer-mode" regeneration of font descriptions

Update of bug #66033 (group groff): Summary: generate grops fonts during a groff build => [devps] support "maintainer-mode" regeneration of font descriptions ___ Follow-up Comment #1: Revising summary. This isn't somethin

[bug #63176] [me] After column-count changes, -me might place running text on page below footnote

Follow-up Comment #9, bug #63176 (group groff): > But some of the running text landing _below_ the footnote suggests something is interfering with this order of events. Having *just* seen this *exact* problem while fiddling with and verifying the function of the "hdfo.roff" example in our Texinf