Follow-up Comment #39, bug #64360 (group groff): [comment #38 comment #38:] > On Thursday, 5 February 2026 17:58:03 GMT G. Branden Robinson wrote: >> Follow-up Comment #37, bug #64360 (group groff): >> >> [much context preserved because this is such a sprawling argument] >> > [much context removed - it's sprawling.]
Hey, look, something else we agree upon! > It's time to re-target the discussion back to the stated purpose of this > "wish" ticket. I guess you're expressing your opinion, because the "Severity" of this ticket is "Normal" and, consulting the "History" section of the Savannah ticket on the Web, has been ever since it was first filed in June 2023. That's 2½ years ago. If it's your view that this ticket has had the wrong severity this whole time, and you have correctly treated it as a "wish" item this whole time, that undercuts your later argument that this request for more flexible whitespace handling on the part of _gropdf_ constitutes some sort of cramdown of a gratuitous change. You've successfully blocked it for an entire _groff_ release cycle...and counting! > Purpose of the ticket. > > Before Branden changes the format of the grout to include some white space, > to > make it more human readable, gropdf needs some changes. It does not use any > groff libraries, so even if those libraries can parse the extra white space, > > gropdf does not. I have a question: given that prior art--in the same source tree!--in the form of "libdriver.a" existed for about 20 years before you started writing _gropdf_, why did you not ensure that _gropdf_ interpreted "grout" compatibly with "libdriver.a"? > What we agree on. > > That humans regularly reading grout are a very small group, possibly just > Branden and I in the main. > > Examining grout files is very useful in debugging, including comparing grout > > between versions to see what has changed. > > Documentation on the precise format for grout (even groff's version) is not > unambiguous. Yup. I'm workin' on it. > I'm not sure if we agree on this one: this ticket describes the "incorrect > behaviour" of gropdf in not supporting white space which does not appear in > current grout, but I am unable to find a "feature change" ticket which > proposes to alter current grout format where the desirability of adding white > > space could be discussed. That's because it's not really a feature change, in my opinion. "libdriver.a" can parse either "dialect" of input (as https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/src/devices/grotty/tests/h-option-works.sh?h=1.24.0.rc2 illustrates), and as far as I've tested, others besides, such as the "trout" produced by DWB _troff_. (_groff_'s output drivers can't actually usefully _render_ that "trout" because other formatters don't use the same output device names groff does. But that's not a difficulty with the _syntactical_ processing of the "trout".) > Sometimes changes to grout will be unavoidable as groff develops further, and > > I hope that I am included in the discussion as to how it might impact gropdf > > BEFORE final decisions are made. Does this 29-month-old ticket not constitute precedent thus, in your view? If not, why not? What makes this decision "final"? Have I demonstrated a categorical refusal to ever revert any change I make? The fact that you are overstating and dramatizing the nature and consequences of this request suggests to me that you realize you're not on solid ground, and are trying to make your position look stronger than it is. If I were in a hurry to cram this down your throat, I wouldn't have been content to let it sit for 2½ years. > What we disagree on. > > I don't find the added white space particularly helpful in aiding > comprehension, perhaps because I have been gazing at grout for longer than > Branden. But I believe "chacun a son gout" so developed one line perl script > > to show grout in exactly the way he wants to see it, but he does not want to > > use it. Correct. That Bell Labs CSRC Unix programmers could assemble and disassemble PDP-11 machine instructions by eyeball (aided by the nicely structured instruction format) didn't inherently make them better C programmers. But this was a hard fact to perceive before the PDP-11 was displaced and other ISAs became more important, and mastery of a single architecture became more obviously distinguishable from thoughtfulness about object file formats, address space management, interrupt handling, and other "generic" but low-level issues. (See, for example, "/* You are not expected to understand this */" at https://web.archive.org/web/20080303040011/http://cm.bell-labs.com/cm/cs/who/dmr/odd.html.) > Equally, I could write a little script which removed the white space to > satisfy my "gout". Except that if the format of grout is altered it means > that > grout before the change cannot directly be compared with the new version, it > > would require an extra step to reformat one of the versions. Correct. It's necessary to "normalize" the grout stream, which as noted affords multiple dialects. *Any* interpreter of trout/grout has to (well, *should*) perform such normalization, since whitespace is so frequently optional. (I'm not making this up; see CSTR #54 and CSTR #97.) If _gropdf_ doesn't cleanly separate lexical analysis from parsing, I begin to perceive a reason for your resistance to this idea, but maybe it's not the case, as you haven't disclosed it. It's possible that you've written _gropdf_ so as to not perform normalization of the input in a careful way, but done it ad hoc. Maybe that even makes more sense. GNU _troff_ works the same way with its input, which has led to some frustrations. Here's an example. When should we treat a tab on a control line like a space? Different implementations make different decisions here, and since troffs tend to mingle lexical analysis and parsing, there are often multiple places in the code where this decision has to be expressed. Humans being humans, they sometimes forget to do this consistently. Further, there are specification difficulties. In the control line... .vs<TAB><TAB><TAB>\" restore previous vertical spacing ...has the `vs` request been given an argument, or not? If so, what does that argument contain? Tabs? A comment? Both? Are those trick questions, and it _has_ an argument, but the argument is null? Spoiler alert--it's unspecified. We could interpret TAB><TAB><TAB> as an invalid argument, or discard it as meaningless nonsense, read past it, hit the comment, and decide that there was no argument after all. > I think this falls under Ingo's definition of a "gratuitious change" (see > <https://lists.gnu.org/archive/html/groff/2026-02/msg00030.html>). In that > possibly the only person, out of regular grout readers, who would find this > beneficial, is Branden himself, and I find no evidence an attempt was made to > > guage support for this change before this ticket was created (apologies if I > > missed it). Why would I need a separate ticket when this one exists? No alteration to "libdriver.a" is necessary, and the only reason I _haven't_ made the change to the formatter itself is...this ticket and your lack of response to it from 15 August 2023 to 6 February 2026! > Finally, I don't think imposing a change to grout which necessitates a change > > to gropdf without prior discussion with gropdf's author is conducive to > cooperative development of a project. I started running this by you in August 2023 and let it sit, awaiting your "long reply [that] will be required", as you put it in comment #32 on 15 August 2023. If that doesn't constitute evidence of patience and prior notice on my part, what duration would? _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?64360> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
