Hi Branden, G. Branden Robinson wrote on Tue, Sep 08, 2026 at 11:33:08PM -0500: > At 2026-09-05T18:12:20+0200, Ingo Schwarze wrote:
>> i'm reporting here instead of on Savannah because Savannah is so slow >> that i cannot use it. Details at the very end of this posting. > LLM = DDoS :( Oh indeed, now it makes sense to me. Nick, Ken, and myself have badly suffered from this artificial insanity on cvsweb.openbsd.org, too. On the other hand, the hostile horde of bots has never managed to bring man.openbsd.org down, however hard they tried, but only because man.cgi(8) is written in C with libmandoc and hence fast enough to simply run away from their sustained onslaught. >> In groff-1.22.4, an empty tbl(7) table resulted in a blank output >> line in terminal output. In groff-1.23.0, it no longer results >> in anything whatsoever, not even in an output line break. > I object, as I often must with respect to your reports, to your > characterization of this behavior as a "regression". Admittedly, i use the the term "regression" more loosely than you do - not only for "a change that breaks documented behaviour", but also for "involuntary change of user-visible behaviour that, on later reflection, does not look useful or desirable." > As I said in February, > "...if mandoc sampled groff in 2010 or so and resolved to pour > cement over every measurable aspect of groff behavior, whether specified > or not, whether documented or not, whether known to be a bug or not, and > proceeded to write all of its automated tests on such a presumption of > utter fixity in the software system being simulated, then the > mdocml/mandoc project set itself up for failure in this area. That may be true. Then again, with a language as loosely specified as roff(7), and widespread practice among document authors and maintainers of "tweak it - in horrible ways if need be when failing to think of any better way - until it comes out with the formatting i want," some amount of implementing bug-by-bug compatibility with groff is actually unavoidable. Consequently, drawing the line between useful test coverage and overtesting is hard - strictly speaking, drawing that line precisely requires a complete language specification. That said, i'm often changing mandoc behaviour and adjusting the mandoc test suite when i can convince myself that the new behaviour provides significant benefit and does not cause widespread or severe havoc in traditional documents. Sometimes, i even adjust mandoc to newer groff even if the benefit is small and it makes some old documents slighly more ugly. However, i do treat changes in user-visible behaviour as regressions until i can convince myself that they are intentional and useful or at least mostly harmless. Such initial classification can of course be changed later, just like a legal presumption can be overcome by disproving it in court. > What I will not do is abandon groff as a living software system or have > Hyrum's Law[...] imposed forcibly upon its developers by another > project. I certainly hope that you don't abandon groff or switch to bugfixing only maintenance mode! > That established, I think the balance of factors is likely in favor of > having _man_(7)'s (and _mdoc_(7)'s) `TS` macro unconditionally break, OK, good. Conseqeuntly, for now, i will make mandoc(1) do that. That will almost certainly be easy to do in mandoc and pose no danger. Should it later turn out that despite initial appearances, there is a downside to doing it in groff, too, that can be revisited in mandoc. > but we must be quite cautious about undertaking any extrapolation > therefrom. That caveat is well-founded. > There's no fatal error here in groff. Since you hit a `.TE` token with > no preceding table, the fact that tbl "gives up" does no harm to the > document. You can start up another table region, and it will render. Acknowledged, makes sense. > The primary reason we want the `TS` macro to cause a break is because a > basic presumption of the _tbl_ formatter is that it has an "entire > output line" to work with, even if it is formatting only one of those > (as with my examples above). That argument makes perfect sense, and looks stronger than my argument about a particular degenerate case. > I can see some *roff users racing forward with a false symmetry, > asserting that _all_ preprocessor token macros should do the same. I would also disagree with jumping that shark. > * With eqn(1), you can have "eqn regions" _that produce no output_. A > widely seen example is: > > .EQ > delim $$ > .EN > > Here, you _absolutely do not want to break the line_. Indeed. Besides, Let .EQ epsilon .EN be a positive real number... is a perfectly valid way of asking for an inline display, even though you would have a point if you were to call it slightly clumsy. Oh, you go on to say just as much yourself. > * pic(1) _could_ be used inline just fine, when typesetting. > * With refer(1), the whole point is to set the citations _inline_, until I have no bull in those fights, but your perspective seems reasonable. [regarding the Makefile] > Well, it's generated by Automake. To see what we actually work on as > developers, consult "doc/doc.am". > ...but that's pretty cold comfort, as it's the single most complicated > Automake script we have by a wide margin. Granted. Wait, what, formatting documentation is what causes most of the work in a project that is, among other things, used most for... formatting documentation? Now, that's a scandal for a change! =:c) Joking aside, the trouble i'm regularly bumping into is that *debugging* absolutely requires working with the generated Makefile and only with the generated Makefile. Looking at *.am will tell me precisely nothing about why make(1) does not do what i hope it would. Finding the root cause of a problem requires fully understanding what make(1) does with the generated Makefile, and once the root cause has been found, figuring out how to convince automake(1) or autoconf(1) or both to instead generate a Makefile that portably does the intended job is a subsequent, *additional* step. Alternatively, as a subsequent, additional step, debugging the make(1) program itself might sometimes be called for, but that also requires full understanding of the generated Makefile as the first step, and whatever is in *.am is completely irrelevant for that task, too. The debugging output of make(1) always tends to be somewhat lengthy, even with a concise, well-designed, hand-written Makefile. The size and complicatedness of the generated Makefile further aggravates the size and complicatedness of make(1) debugging output to the point that so far, it prevented me from finding the root cause of the latest problem. It's not the first instance where this effect erected a roadblock for some time. > I have no more fruitful advice; sometimes Savannah gets so borked by the > bots that it kills my own work on groff for a day. The problem is not > fundamentally technological, but economic and social. Acknowledged, i feel your pain. That sucks indeed. > We will not be freed of the effects of negative externalities until the > tech oligarchs are dragged through the streets of Seville in chains. May i suggest doing that in Yakutsk instead, preferably during winter? Yours, Ingo
