bug-groff
[Top][All Lists]
Advanced

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

Re: Regressions in UTP document (was: removing the .IX macro from the ms


From: G. Branden Robinson
Subject: Re: Regressions in UTP document (was: removing the .IX macro from the ms package in 1.23 breaks old documents)
Date: Fri, 4 Oct 2024 04:09:12 -0500

Hi Deri,

At 2024-10-04T03:37:26-0500, G. Branden Robinson wrote:
> It therefore looks to me like we traded one problem in groff 1.22.4
> for another in groff 1.23.0.  Not the happiest outcome, but neither
> does it make the story of groff over the past 6 years or so one of
> unalloyed regression.

Outside of your changes to gropdf, I mean--_everybody_ is a fan of
those, myself included.  :)

> I'll continue investigating.

It looks like the fix for #59812 _did_ fix the issue with groff 1.22.4;
when I build UTP 1.0 with commit
633de5c27e299ba9421ca8ba298a5bc90e56ff1c (2021-02-25), neither the table
(p. 398, #386) nor the text after it exhibits line numbers in the
margin.

Unfortunately, commit 950f92e25f3f446d9e4d4560e1563c5944839d8a
(2022-11-28) introduced a new, different problem; after a table, line
numbering got switched back on if it had ever been on (without the `ln`
register being reset to zero).  Screenshot attached.  This is the one
you reported in this thread (well, one of the three).  I double checked
by backing up 2 commits (to skip over a new regression test), and sure
enough, commit 3b09ab4e5020dd2feb019193c710393a604fbf35 (2022-11-29)[1]
shows neither problem.

My hypothesis is that I wrote incorrect generated *roff in
src/preproc/tbl/table.cpp.  I know where to look, and thanks to this
information I have a pretty good idea how to write a regression test for
this problem so that this bug, like line numbering, stays dead once you
kill it, until the user directs its resurrection.

I'll probably end up filing a Savannah ticket for this (it _is_
observable in a release), and marking its severity Important as a
regression, so that distributors are nudged to cherry-pick it.  (Though
as far as I know, only Colin Watson of Debian/Ubuntu actually bothers.)

I opine again for general edification that it's really a damn shame that
GNU tbl doesn't set up an environment for every TS/TE table region it
encounters.  Instead it creates a bajillion strings and registers and
laboriously saves and restores tons of environment state without
switching environments.  Anyone could tell you that's going to be
fragile (it's why the "struct" or "record" data type was invented)--and
yet again and again we hit bugs in tbl that come down to this.  Some of
them even originate in code written by people other than me.  :-O

Another wishlist item for an ambitious contributor, or a future me...

Regards,
Branden

[1] Yes, the earlier commit has the later date stamp.  This is due to
    rebasing and "author dates" vs. "commit dates" being different.

Attachment: utp-1.0-line-numbers-after-table.png
Description: PNG image

Attachment: signature.asc
Description: PGP signature


reply via email to

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