[bug #66392] full-service macro packages lose track of hyphenation mode in environments other than 0

Follow-up Comment #39, bug #66392 (group groff): At 2025-02-07T19:25:31-0500, Peter Schaffter wrote: >> Hence my saying that deferring bug #66387 until post-1.24 is the >> path of least resistance. (Other than your resistance to it. :) > > Seems as if every time I go to say something on this thre

[bug #66387] [troff] the hyphenation language is global; should be a property of the environment

Update of bug #66387 (group groff): Status: Fixed => None Assigned to:gbranden => None Open/Closed: Closed => Open Planned Release: 1.24.0 => None _

[bug #66387] [troff] the hyphenation language is global; should be a property of the environment

Follow-up Comment #8, bug #66387 (group groff): commit 7f643d1f765c53437471207ffbff11d01e38f57e Author: G. Branden Robinson Date: Fri Feb 7 18:50:18 2025 -0600 [troff]: Revert most of Savannah #66387 fix. Retain unit test, which fails at this commit. See Savannah #66392

[bug #66758] [mm] commit 88cd50aa causes troff fatal error when using present.tmac

Update of bug #66758 (group groff): Status:None => Confirmed ___ Reply to this item at: ___ Message sent via Savan

[bug #66392] full-service macro packages lose track of hyphenation mode in environments other than 0

Follow-up Comment #41, bug #66392 (group groff): I jumbled a couple of statuses up. Let me try that again. Removing status and assigning to Dave; it's not clear to me what the proper resolution of this ticket is; it's "invalid" with respect to the current state of the repository (as of a few min

[bug #66392] full-service macro packages lose track of hyphenation mode in environments other than 0

Update of bug #66392 (group groff): Status: Confirmed => None Assigned to:gbranden => barx ___ Follow-up Comment #40: Done. commit 7f643d1f765c53437471207ffbff11d01e38f57e Auth

[bug #66387] [troff] the hyphenation language is global; should be a property of the environment

Follow-up Comment #7, bug #66387 (group groff): [comment #6 comment #6:] > Reopening. Dave and Peter object strenuously to this change. See bug #66392 for aforementioned strenuous objection. ___ Reply to this item at:

[bug #66686] [troff] `\w` escape sequence rejecting delimiters roffs have accepted for decades

Follow-up Comment #7, bug #66686 (group groff): commit ec34f01715bee231e9838b0c5702c76364c633a3 Author: G. Branden Robinson Date: Thu Jan 30 08:17:14 2025 -0600 [doc,man]: Restore | to forbidden delimiter list. Not really forbidden, but deprecated -- and silently accepted anyway

[bug #66392] full-service macro packages lose track of hyphenation mode in environments other than 0

Follow-up Comment #38, bug #66392 (group groff): [comment #35 comment #35:] > But what _is_ most reasonable? This raises the thorny question of how > environments should be initially populated--the very issue you said (comment > #23) you didn't want to adjudicate before 1.24. Unfortunately, I d

[bug #66392] full-service macro packages lose track of hyphenation mode in environments other than 0

Follow-up Comment #36, bug #66392 (group groff): At 2025-02-06T22:52:09-0500, Dave wrote: > Follow-up Comment #34, bug #66392 (group groff): > > [comment #33 comment #33:] >> Maybe a better model is for the hyphenation code _and_ language >> to be global instead. Dave suggested this, > > This is

[bug #66392] full-service macro packages lose track of hyphenation mode in environments other than 0

Follow-up Comment #37, bug #66392 (group groff): [comment #36 comment #36:] > So while it seems we all agree he was astonished by 1.23.0 behavior, > it's not clear what he was...I won't say "endorsing", but refusing to > condemn. We seem to find ourselves in a position where, instead of speculati