On 13.10.24 11:24, G. Branden Robinson wrote:
Hi Joerg,
hi branden,
it seems it would probably be best to just agree to disagree and move on, but
...
At 2024-10-13T11:03:52+0200, joerg van den hoff wrote:
but I really believe the line should never have been deleted in the
first place (I think the working hypothesis should better be "even if
I do not see why it is there and even if it seems superfluous to me,
it is there for a reason"
I think a better hypothesis is "have good automated test coverage", so
that you can delete stale code and otherwise refactor.
no, that is not true, simply because you can't test everything. you removed the .ll -8n as "doing
nothing in all my trials" and if you have no idea why is there in the first place you hardly can
test reliably whether its deletion harms ;). more seriously: test coverage is never 100% (far from
it). removing code simply because it does not affect existing tests, however comprehensive, sure is
not a good idea.
so the approach "when in doubt, don't touch" seems really the preferable one to me. at least with
stuff like this.
Our test coverage may have been inadequate here; I'll see what I can do
about it.
that's always good, sure.
(and, of course, I personally believe the same is true for the .IX
removal ;)).
If you've read my earlier messages about this, then maybe you can answer
some questions.
What is `IX`'s interface on the following ms implementations? By
"interface", I mean not only "what arugments does the macro accept?",
but "what output or result can the macro user rely upon?".
1. DWB 3.3
2. Solaris 10
3. Solaris 11
4. groff 1.22.4
I do not know. and I am not sure where this argument should go and what should
follow from it.
my position/experience basically is: groff (and legacy troff before) is "user software". macro
packages are there to help "simple" users along. if there is a macro that was around 25 years ago
(.IX), even if never well documented, never doing something fancy but only doing something helpful
to some users some of the time, than there is no good incentive (or none at all...) to just delete
it 25 years down the road and cause poor users like me some headache ;).
in any case, your line of reasoning and justification for deletion of .IX seems to boil down to "not
official, not documented, not canonical part of ms, useless".
my reasoning is "worked for 25+ years (which, let's face it, is quite a long time ;)) in groff-ms, I
found it because documented in some ms-related tutorials and I deemed it useful and used it. 25
years later current maintainer decides to do away with it. bad."
bottom line: no, you will not convince me that your decision is the correct one in this respect no
matter what arguments you personally consider valid justification to do so: .IX (4 lines??) should
not have been removed from s.tmac. keeping it does zero harm (maybe beyond hurting you personal
feelings about source code economy and tidiness ;)), deleting it does non-zero (however small) harm
(has done, matter of fact).
but I of course take note of the fact that you disagree and, as a maintainer, have the last word
(sort of...). so I have to work around your decisions when+where they get into my way (to the extent
that my modest knowledge of groff suffices: I actually use groff just as a tool and want to
write/format stuff, not play or fight with groff). which is a pity but if it can't be helped, so be it.
but this does not change my principle opinion: like with removal of the `.ll 8n' line from the .XA
definition such removal of (really only) apparently stale/useless code risks to (and indeed does:
exhibits A and B are .IX and .XA) break decade old user documents. this is a too high price to pay
just for the sake of "cleaner" code: better to unnecessarily keep some "noise" in the sources
(really stale code) than to inadvertently destroy some "signal" (relevant stuff).
coming back to "agree to disagree" -- let's probably draw a line here: at least the `.ll -8n' is
back (good) and you seem to refuse to restore .IX. (unfortunate for affected users (>= 1)). that's
that, then...
best,
joerg
Regards,
Branden
