Hi Ingo, At 2026-09-09T18:54:39+0200, Ingo Schwarze wrote: > 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.
Savannah is inherently a more interactive kind of site, or at least the bug tracker is. On the other hand, like so many "web apps" of a certain age, it's written in PHP, the worst possible choice, so I hold no real hope for respite. Much earlier in my career, I had to work with PHP professionally. Never again. > >> 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." I use a simpler, broader, and less provocative(?) term for that: "defect". > > 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. I entirely agree. A good number of the arguments that have arisen on this mailing list have been the result of people having closely read CSTR #54 and developed conflicting, highly confident opinions about what it implies for an implementation. > 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. I have no quibble with your process, merely your terminology. :) > > 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! No plans for that. Some day, the bus may hit me in spite of my desires. There are other projects I'd eventually like to make time for, and that time will have to come from groff. But for now I have ~475 fish to fry. > > 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. [...] > > 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. Thinking further about this, I've changed my mind. Don't have a heart attack--I don't think the change will affect you. :) Here's my new thinking: If _tbl_ itself is the thing that absolutely must have a fresh output line for its computations to make any sense, then: ..._tbl_ should put a `br` request into its output itself. This change also supports another reform I've been wanting to make: creation of a separate environment (based on the current one) for table rendering. https://savannah.gnu.org/bugs/?66295 The reason my new thinking is supportive of that change is that the contents of a partially collected line _are part of the environment_. > > 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, In my usage, "inline" and "display" are mutually exclusive, but I think I see what you're saying. > 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. Not necessarily clumsy. Sometimes, delimiters may be difficult or inadvisable to use. Perhaps you'll be inlining a math expression adjacently to some user-controlled string(s), and you therefore don't know what crazy characters they'll inject that might collide with your delimiter. Granted, in principle, there's this approach: Let \*[user-eqn-start-mark]\c $epsilon$ \*[user-eqn-end-mark] be a positive real number... ...but it hardly seems less clear than this. Let \*[user-eqn-start-mark]\c .EQ epsilon .EN \*[user-eqn-end-mark] be a positive real number... The whole point of eqn delimiters is to pack stuff onto the same _input_ line, and if you're having to break it anyway, the feature loses its applicability. Granted, people operating a Teletype Model 37 at 150 baud likely appreciated the threefold reduction in character count. I learned that the Model 33, which I've seen in the flesh at a university computing center in Oslo now many years ago (it was a museum piece even then), ran at _110_ baud. Good grief. > > * 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. You sort of do in the latter. _mdoc_(7) basically reïmplements refer(1)'s bibliography format. groff_mdoc(7): References and Citations The following macros make a modest attempt to handle references. At best, the macros make it convenient to manually drop in a subset of refer(1) style references. .Rs Reference start (does not take arguments). In a section titled “See also”, it causes a break and begins collection of reference information until the reference end macro is read. .Re Reference end (does not take arguments). The reference is printed. .%A Reference author name; one name per invocation. .%B Book title. .%C City/place. .%D Date. .%I Issuer/publisher name. .%J Journal name. .%N Issue number. .%O Optional information. .%P Page number. .%Q Corporate or foreign author. .%R Report name. .%T Title of article. .%U Optional hypertext reference. .%V Volume. refer(1): Bibliographic records A bibliographic record describes a referenced work in sufficient detail that it may be cited to accepted standards of scholarly and professional clarity. The record format permits annotation and extension that a document may use or ignore. A record is a plain text sequence of fields, one per line, each consisting of a percent sign %, an alphanumeric character classifying it, one space, and its contents. If a field’s contents are empty, the field is ignored. ... %A names an author. If the name contains a suffix such as “Jr.” or “III”, it should be separated from the surname by a comma. We recommend always supplying an %A field or a %Q field. %B records the title of the book within which a cited article is collected. See %J and %T. %C names the city or other place of publication. ... > [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'm unhappy to hear this. I haven't attempted a groff build lately with MAKE=bmake, and I should. I'll try to ensure I do that before cutting 1.25.0.rc3. > May i suggest doing that in Yakutsk instead, preferably during winter? Inspirational viewing: https://en.wikipedia.org/wiki/The_Way_Back_(2010_film) At 2026-09-09T21:27:11+0200, Ingo Schwarze wrote: > Hello Branden, > > Ingo Schwarze wrote on Wed, Sep 09, 2026 at 06:54:39PM +0200: > > G. Branden Robinson wrote on Tue, Sep 08, 2026 at 11:33:08PM -0500: > > >> 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, As noted above, I now intend not to modify the `TS` macro definitions, but GNU tbl itself. This breaks the "code freeze" (just as changing the macro packages would), but that lies in ruins anyway for several reasons, all of them good (improving memory safety, mainly). > > OK, good. Consequently, 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. > > Done, see the commit and credits below. Thanks! Regards, Branden
signature.asc
Description: PGP signature
