bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #58736] -me macros: footnote breaks two-column output


From: Dave
Subject: [bug #58736] -me macros: footnote breaks two-column output
Date: Sun, 19 Jul 2020 11:50:19 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Firefox/45.0

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]