Follow-up Comment #5, bug #58736 (project groff): "Soon" is not among my expectations when opening groff bugs (I've opened bugs that have garnered no response for years), especially ones in macro packages that are essentially abandonware.
My intent is to put bugs where they can be prioritized and addressed when it makes sense. Something like bug #57616, tripped in core groff just from using certain words in running text in the wrong place, should have higher priority than this one tripped by a particular combination of macros in a little-used macro package. But the two require different areas of expertise to debug, so it's not that straightforward. Of course, the expertise gap in -me applies to all (known and yet-to-be-discovered) -me bugs. Savannah unfortunately requires -me bugs be categorized under "Macro - others," so it's hard to tell how many are filed here. I've opened at least eight, with bug #58447 having the most severe result, though probably also being among the least likely to be encountered. I try to always put "me" at the start of the summary line, though I see I've been inconsistent about using "me:", "me macros:", and "-me macros:", and forgot it altogether at least once. > Eric Allman occasionally speaks up on the TUHS mailing list, but he may > consider himself retired--perhaps LONG retired--from maintaining me(7). Yeah, if someone asked me to debug code I hadn't looked at in over 30 years, my first thought would be that a person who's never seen the code before and I would be starting in about the same place. But I don't see any down side to asking. And, true, aside from Eric, there may not be a good candidate for troubleshooting -me problems. I find the -me code impenetrable. A few email-list regulars (Tadziu, Ingo, Ralph) could probably figure them out if they had the time and motivation. George Helffrich <http://savannah.gnu.org/users/georgeh> seems to have some expertise, in that he submitted a patch for -me bug #57638--albeit a bug he introduced three years earlier, which speaks to the danger of not having regression tests. Still, without downplaying this danger, on the other hand I'd point out: * While we don't have a sizeable -me corpus like we do with -man, the four doc/*.me documents in groff's source tree should catch any blatant problems. * Given the age of the original macro set and the software-development methodology widely used at the time, the original development probably included limited or no regression testing, which could be responsible for the existence of many of these current bugs. So continuing to develop without this safety net, fixing known bugs with the potential of inserting new ones as a side effect, doesn't strike me as a step backwards. * In fact I'd hazard that modern revision control will make any regressions discovered in the future easier to pinpoint (as I did in 57638); it's bugs in the historical -me code that are the least tractable. But until someone volunteers to take on these risks and challenges, perhaps documenting all these bugs is best--though even that isn't easy for ones like this one and bug #58447, where merely describing how to trigger them requires an essay. And it's tricky with ones like bug #55060 and bug #58682, where the very problem is a discrepancy between documentation and functionality with it being unclear which should be considered correct. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?58736> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
