Follow-up Comment #12, bug #67602 (group groff): At 2025-10-21T21:41:18+0100, Deri wrote: > On Tuesday, 21 October 2025 18:52:00 BST G. Branden Robinson wrote: >>> Currently git is "red" because neither Groff-man-pages.pdf [...] >> And the tree _isn't_ red, it's green--because we don't have a test >> script that checks PDF bookmarking for correctness. > > Ok, its only red if a test fails.
Right. That's how continuous integration systems work.
If the system is functionally broken but the tree's not red, then one
has failed to implement an automated test that turns the tree red.
> I just meant that pdf.tmac was not working properly after your fix,
I acknowledge that, and I've pushed a reversion of my false fix.
> and a cursory view of the change was enough to know it could not work.
It takes me more than a cursory view for me to understand "pdf.tmac"'s
hyperlinking machinery, starting with its unhelpful and unilluminating
macro names: everything link-related is an "href", even where PDF has
other terms for relevant concepts, and even where the obvious influence
HTML uses a different element type, as with `<a name="whatever">`.
In my opinion, a lot of the hyperlink machinery in "pdf.tmac", which I
vigorously acknowledge was not your invention but someone else's, seems
preoccupied with leveraging the user's superficial familiarity with HTML
markup and Unix command-line option syntax, rather than embarking on a
design from a starting point that considers the shape of the problem
that needs to be solved.
I think we see similar issues in some groff extensions to the _ms_
package, where properties are indirected through multiple levels of
dereference without explicit motivation.
Designs that I don't understand, or that seem to be more complex than
necessary to achieve the task at hand, rapidly confuse me.
>> Something that fragile should probably have a unit test for it.
>
> Please expand on what you mean by "fragile"? Is it because you have
> now twice broken code that was working?
Yup. Unless I'm significantly more stupid or careless than the average
groff user or developer, if I repeatedly screw something up, others are
likely to as well.
I invite you to make a case for my unusually high levels of stupidity
and/or carelessness.
>>> I did mention in comment #5 that you should retain the current
>>> api, so I don't understand why pdf:lookup-value has "vanished".
>>
>> _At the time_, it didn't seem necessary to retain while solving the
>> problem. Happy to restore that string name if it is.
>
> The answer is in my previous comment. -result tells you if the lookup
> is successful, -value contains the text associated with the named
> destination.
I've put it back now. However, as this is an internal interface with
few points of exercise even inside groff itself, I'd suggest we not get
too wedded to it.
>>> I understand your desire to reduce the large document production
>>> time down from 40 minutes to 30 seconds,
>>
>> I wonder who put that notion in my head. ;-)
>>
>>> which is what it took before you made changes to pdf.tmac whilst I
>>> was on a sabbatical.
>>
>> True, and you've raised this point before--and as I noted then, you
>> similarly swooped in after a period of inactivity with some changes
>> while I was about four days into bereavement leave, so to speak.
>
> You have written before
>
> "(Since you're not on the _groff_ list for a while, you may not know
> that I had a death in the immediate family this week and, in an
> employment context, I'd be on bereavement leave right now.)"
>
> And you are absolutely correct, I was not on the groff list (but
> remained on groff_bug), so our behaviours were different, you were
> aware of my sabbatical, I was unaware of your sad bereavement.
I see. I guess you simply had exquisite timing.
There are of course ways to remain abreast of groff list traffic
without being subscribed, starting with GNU's list archives.
> I am sorry if my commits during your bereavement caused any pain for
> you, I would have delayed them if I had known.
Not pain. It simply looked like vulturish opportunism. Whether it was
or was not isn't a major concern of mine; I raise it only because you
repeatedly assert a territorial attitude about gropdf without answering
a question I've put to you I think at least 3 times now without
response: do you want the same deal with gropdf that Peter Schaffter
enjoys with _mom_(7)?
> Your conduct then did upset me, because you knew I was on sabbatical,
> you also knew I was against using a looping solution (my grandsons
> "solution" if you remember) for performance reasons. I, on the other
> hand, had no idea of your bereavement. And your commit here suffered
> one of the same deficiencies as your sabbatical commit, namely it did
> not return the text associated with the named destination - which is
> why it did not work with mom, a fact you recognised at the time.
I tend to forget things about software systems if I don't have
documentation or automated tests to remind me.
>> My advice is to spend less time expressing offense over regressions.
>> Writing scripts to catch them is a better use of everyone's time.
>
> I don't think I was expressing offence, merely stating that you have
> "previous" in this area.
Your erstwhile sabbatical status is irrelevant to that point, because I,
like anyone else, can make a given mistake (or a similar one) more than
once, especially when, as noted, we lack documentation or automated
tests in an area to keep us honest (or, perhaps more to the point,
competent).
When you're _not_ on sabbatical, you could perform code reviews if you
wish, which could be helpful. However, code reviews are best performed
without superfluous rehearsals of past grievances.
>> We have over 280 examples in the tree already of how to do that.
>>
> All written in bash (+ utilities I infrequently use), not something
> I'm very conversant with.
In groff at least, you don't often write C++ either, but you seem to
have flawlessly executed your contribution of direct color support (SGR
38 and SGR 48 escape sequences) to grotty(1). (Should it prove to have
a bug, I won't think less of you: people make mistakes...and there isn't
an automated test for it...)
You can abstain from writing automated tests for any reason you wish;
this is a volunteer project. What you shouldn't do is pretend that
nonexistent ones are there and express surprise when a colleague breaks
things that don't get tested and then pushes "anyway". The tree isn't
red if "make check" or "make distcheck" don't tell us that it is.
We have many automated tests that have properties of integration tests;
for example, some of my tests for the _mm_(7) package compare documents
in nroff to canned pre-formatted models in plain text; any change in
vertical margins, page offset, line length, break locations, glyph
selection, and sundry other formatter operations, not to mention failure
of the macro package to load, will thereby be revealed.
In a sense, most or all of our automated tests that run the formatter
at all are integration tests alongside whatever other properties they
possess because they run GNU troff via "test-groff", which requires that
the build directory be sound enough for all commands in the pipeline
the groff command runs to be present and executable, and that the
resources in the font and tmac directories be present and correct enough
to work.
A feature that is not automatically validated is not complete.
Robust systems arise primarily not from the personal virtues of the
implementor(s), but from consistently applied empirical tests of their
soundness. This principle underlies quality assurance in many fields.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67602>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
