Follow-up Comment #30, bug #66392 (group groff): At 2025-02-04T15:39:12-0500, Dave wrote: > Follow-up Comment #29, bug #66392 (group groff): > > [comment #26 comment #26:] >>> roll back the change making hyphenation language per-environment. >> >> That is what I will have to do, I reckon, since no one has even >> ventured that they perceive a problem in comment #0 of bug #66387. >> >> I'm surprised. > > I can read the above multiple ways. You're surprised that: > 1. That bug was opened three months ago and fixed days later, and only > now is anyone raising issues with it?
...not exactly. _Is_ there an issue with it? I mean with my diagnosis of the problem and the shape of my solution. > 2. No one has identified a problem with the original bug description, > only the timing of the change? Is the timing of the change the problem, or the missing alterations to the full-service macro packages? > 3. Issues with the change are being posted here rather than in the > ticket that precipitated the change? Nah, I don't sweat that. In fact, if people don't disagree with my (1) perception of a problem existing; (2) my root-cause analysis of it; or (3) the form of my solution, then this is a better place to comment than bug #66387 is. > 4. Something else? Apart from tracking a pile of dependencies, release management isn't really something we do in Savannah tickets. It's probably better mooted on the mailing list. Incidentally, I did start a chinwag over the behavior described in bug #66387. https://lists.gnu.org/archive/html/groff/2025-02/msg00004.html (I know Dave's already found the thread.) I think scheduling chins are better wagged in a separate thread from that. To abuse this ticket to talk about something _really_ unrelated, I'm closer to sorting out bug #66675. I figured out the thing I was stuck on. A confluence of my least favorite things about groff came together to hex me. (Lack of existing test coverage, varying string null-termination practices in the `symbol` and `string` classes, and the [in my opinion] overuse/overloading of null pointers to carry semantic meaning about object state. The last I think is a memory-starved C programmer's idiom.) > (I include #3 because it's one way I can read the above, though I'm > pretty sure that's not what you meant. But I might be surprised by > what surprises you.) Not today. But I may prove unpredictable yet! _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?66392> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
