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

[Dave]

URL:
<https://savannah.gnu.org/bugs/?58736>

Summary: -me macros: footnote breaks two-column output
Project: GNU troff
Submitted by: barx
Submitted on: Wed 08 Jul 2020 12:40:28 PM CDT
Category: Macro - others
Severity: 3 - Normal
Item Group: Incorrect behaviour
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release: None

_______________________________________________________

Details:

This bug shows up in both PostScript and terminal output. The example below
uses nroff because that's easier to show in a bug report. It happens on a
recent groff build from git and in official groff release 1.22.3.

This input file:


A little introductory text.
.2c
This text appears in the first column of two-column output.
.bc
This text appears in the second column of two-column output.
.1c
Single-column output resumes.


when run with "nroff -me", produces:


A little introductory text.
This text appears in the This text appears in the
first column of two-column second column of two-column
output. output.
Single-column output resumes.


(plus a lot of blank lines filling out the "page"). Now change the first line
of the input file to these four lines:


A little introductory text.*
.(f
*A footnote.
.)f


Now, the line "Single-column output resumes," rather than appearing below the
two columns as it should, is pushed to the bottom of the page, below the
footnote. It looks basically like this (though I've greatly reduced the
number of blank lines):


A little introductory text.*
This text appears in the This text appears in the
first column of two-column second column of two-column
output. output.











____________________
*A footnote.
Single-column output resumes.





_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?58736>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[G. Branden Robinson]

Update of bug #58736 (project groff):

Status: None => Confirmed

_______________________________________________________

Follow-up Comment #1:

Can confirm this.

_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?58736>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[G. Branden Robinson]

Follow-up Comment #2, bug #58736 (project groff):

I guess a reasonable next step is to find out if the me macros misbehave
similarly elsewhere, or if this problem arose due to groff (either our fork of
me(7) or something within the typesetting logic itself).

_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?58736>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[Dave]

Follow-up Comment #3, bug #58736 (project groff):

The footnoted input file produces the same incorrect PostScript output in
Heirloom troff, and the unfootnoted one produces the same correct PostScript
output. (Heirloom nroff output from both input files is pretty hopelessly
broken.)

According to the header blocks of the respective files, groff's -me macros are
forked from version 2.31 of Eric Allman's original set, and Heirloom's from
version 2.14. If there's a repository of these versions of the -me package as
they existed before forking, I can't find it.

_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?58736>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[G. Branden Robinson]

Follow-up Comment #4, bug #58736 (project groff):

Thanks for doing the research on this, Dave.

Hacking full-service macro packages like ms, mm, and me without any test suite
for them, or even a corpus of example documents we can regression-test with
(like man) fills with dread, and little hope we can resolve this soon.

Think this might be worth documenting in a "Bugs" (sub)section of groff_me(7)?
Maybe in meintro.me and meref.me as well. That wouldn't enable us to close
this bug, but it would serve as warning to interested users and might get a
little more light thrown on the issue.

Eric Allman occasionally speaks up on the TUHS mailing list, but he may
consider himself retired--perhaps LONG retired--from maintaining me(7).

Thoughts?

_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?58736>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[Dave]

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.

Post by G. Branden Robinson
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/

[Dave]

Follow-up Comment #6, bug #58736 (project groff):

Replying to myself:

[comment #5 comment #5:]

Post by Dave
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

I realize my prolific bug-opening is skewing these results, but for
comparison, currently mm has 8 open bugs, ms 4, man 7, mdoc 6, and mom 1. By
those numbers, adding a specific -me category to savannah seems justified.
-me is also the only full-service macro package lacking its own category.

Post by Dave
ones like this one and bug #58447, where merely describing how
to trigger them requires an essay.

Perhaps a better thing for the -me documentation to include than complete
descriptions of these bugs is links to the savannah bug reports still open at
the time of the release.

_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?58736>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[G. Branden Robinson]

Update of bug #58736 (project groff):

Category: Macro - others => Macro - me


_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?58736>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/