Hi Robert, At 2025-06-07T09:25:23+1000, Robert Thorsby wrote: > On 7/6/25 09:07, Deri wrote: > > On Friday, 6 June 2025 23:10:35 BST Robert Thorsby wrote: > > > When proposing changes to long-standing *roff "idiosyncrasies" I > > > suggest you consider the adage festina lente. > > > > "More haste, less speed". So, you are suggesting I should make the > > changes one line at a time over an extended period! :-) > > No. I am suggesting that if you see something that you did not > understand or expect then you should take the trouble to find out why > it was done in that particular manner and not merely propose a > solution to what may well be a misunderstood problem.
Color support was added to groff in 2001 by Werner Lemberg and Gaius Mulley. Initially, files named "color.tmac" and "color-html.tmac" were created. https://cgit.git.savannah.gnu.org/cgit/groff.git/commit/?id=60e517ebe912e2d304a40149a061fae2f0d5fd6e Not long after, Werner moved contents of these files into "ps.tmac" and "html.tmac". https://cgit.git.savannah.gnu.org/cgit/groff.git/commit/?id=1cfd21b748f324dc01597d18a20da172a5ff13e0 Werner and Gaius are both still around. (We don't hear much from Gaius here, but he's quite active in developing GCC's Modula-2 front end.) What, specifically, should we be asking them? Would you be more comfortable if Deri solicited them for "Reviewed-by:" annotations for future Git commits in this area? > You must remember that you are proposing changes to *roff itself, To be precise, Deri's proposed changes are not to formatter logic, but to macro files. That doesn't mean they shouldn't be done with care, but they are more easily managed. > and with very little idea of what you are doing. I see no evidence that Deri doesn't grasp the nature of what he's proposing. > BTW, making changes one at a time The appropriate size for a changeset is a subjective matter and in my opinion is more of an art than a science. I'm sure people would have drawn boundary lines differently than I have in several cases among the 8,000+ commits I've made to groff's Git repository by this point. (I'm sure there's been at least one case where I now wish I had done so.) I would agree that when debugging or troubleshooting, slicing changes finely is a wise practice. It's less appropriate for landing a sketch, proof-of-concept, or prototype. In my experience, a manager who's tasked an engineer with delivering one of these will lack interest in the first N iterations starting from a null program or "Hello, World", and doesn't care to observe the program's perturbation toward a working state until there is some "meat on the bones". > and allowing time for enlightened comment I think that's what Deri's done here and with his `grotty -t` change at the end of last month. He's sent patches to the list and attached demonstration documents. > is programming 101. I think this part of your remark is somewhat (a) condescending, as Deri is an experienced groff developer with a longer tenure than mine; and (b) topically misplaced; you're identifying sound practice in _collaborative software development_, particularly with respect to the second part (soliciting feedback on contemplated changes). That's an appropriate consideration for groff, but it's not "programming" per se, which is an activity a human carries out upon a machine. The exchange of commentary (enlightened or otherwise) is a _social_ process. > Those who ignore history are condemned to repeat it. Is there a specific unfortunate historical episode you see or fear being replayed in this instance? Concretely, is there benefit in groff having its own bespoke color repertoire, distinct from the HTML standard and X11 implementation? If there is, could you motivate and contribute a specification for it? Regards, Branden
signature.asc
Description: PGP signature
