[returning to this after postponing it last week] [replying to 2 messages; Joerg inadvertently replied to me only privately with one of them, but graciously extended permission to quote him on the list]
At 2024-10-03T15:33:11+0200, joerg van den hoff wrote: > thanks for bothering to reply so thoroughly. I have interspersed a few > comments below but up front just this: I principally regard changes > breaking backward compatibility in software like troff/groff as really > undesirable. I share the principle. It may be that I see more tradeoffs than you do. > I would never have expected elimination of a macro definition from an > ancient macro package like ms in a new groff release If I read this literally, it is a very broad statement. A macro definition is anything created with the `de` or `am` requests (or their GNU troff variants). As I noted in my previous response, a conception this broad means that there is no such thing as an "internal" macro in a package. For one thing, such a conception is destructive of the principle of software modularity. For another, it clearly runs against observable practice even in "old troff". If you look at the sources of the Seventh Edition Unix man and ms packages... https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/lib/tmac/tmac.an https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/lib/tmac/tmac.s ...you will see _many_ macro names that appear nowhere in documentation, macros with very strange names, and moreover, macros that groff's implementations of man(7) and ms(7) have _never_ implemented, and thus--by your definition of an interface--constitute extensive incompatibilities with the packages as they existed in 1979 and throughout the 1980s. And, yet, man(7) and ms(7) documents from the 1980s largely work well with groff. Why? Because these packages had _documented interfaces_... https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/man/man7/man.7 https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/man/man7/ms.7 ...to which authors employing those macro packages largely stuck. It's my strong belief that _that_ is the contract between the package author and package user--not the list of symbols that a macro package injects into the macro name space. It is easier, perhaps, to lose sight of this principle in AT&T troff than in GNU troff, because the former restricted its identifiers to two characters in length. > (that's why it took me non-negligible time: I looked everywhere > (especially in my scripts massaging the output (resorting the dit > output such that TOC is moved to the right place and stuff like that) > before I looked into s.tmac to inspect the IX definition for clues -- > which was no longer there...). I would plead with people to read the release notes/NEWS file. Its use to document user-visible changes is not my innovation, but a groff practice going back to about 1990. Just scroll down to the bottom of the file to see. https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0#n3417 > but I do not want to get into a lengthy argument about this issue We may be too late on that front... ;-) > (if only for the reason that re-implementing this trivial macro is ... > trivial :)). you maintain it, you decide. if you would reconsider > that decision, I would welcome it, if not, so be it. I'm pushing back on your case here not because I'm particularly determined to see `IX` eradicated from groff ms. Of itself, I don't care about it very much. But the principle of software modularity is _hugely_ important to me. If you use a undocumented/internal macro from someone else's package, you have to accept that your document may break or alter its behavior in a surprising way in the future. If you need me to locate some statements from authorities in the field of software engineering championing the principle of software modularity, I am willing to do so. I'm not going to say that you can't play with whatever you find. groff is an open system. Play is exercise, and exercising a system is one way we work the bugs out of it. But when you employ undocumented interfaces, you accept risk. The problem I'm seeing in our present discussion is that you didn't _know_ you were accepting risk. We should do something about that if we can. > > Both were true to the best of my knowledge at the time I made > > them--the > > I do not doubt that you were under that impression at the time but > this does not make it "true" which ideally is an absolute category, > independent of one's own knowledge :). I agree strongly with your qualifier "ideally" here, in the sense that your perspective might be dangerously Platonic. I'm not a sophisticated enough logician to defend the proposition that there exists an unbounded class of propositions that are unverifiable and/or unfalsifiable under any logical system powerful enough to be useful, but when I cast it that way it sounds close enough to Gödel's Incompleteness Theorems that that's the way I would bet. The more interesting issue is a practical one. How are groff developers to acquire the knowledge they need to avoid inadvertently breaking users' documents? Part of the answer involves establishing a common understanding of _what_ constitutes the interface of any component of the system, explored at length above. Another part is getting a corpus of exhibits into the hands of the developers that they can apply to the objective of regression testing. Except for Mike Bianchi's test suite for gdiffmk(1), groff pretty much just didn't do this at all until groff 1.22.4, when our previous maintainer Bertrand Garrigues wrote a pair of tests that would detect gross failures of rendering. These were useful. I saw them and they were good. So I made more. > "not sound" referred to that circumstance: I read the release note as > "because A and B are given it is justified to do C". and the stated > premises do not hold up to closer scrutiny... I'd say rather that one of the premises was/is dependent on robust communication between users and developers. These are roles, not individuals. In my role as a user I've filed _many_ bugs against groff. > undocumented via manpages might very well be. But that's important. The man page for a macro package, as a rule, is composed by the author (or maintainer) of the package. It reflects the developer's knowledge and intentions of _what constitutes the package interface_. If someone else comes along and writes about a package's internals, and you (yes, YOU) decide that those things are every bit as much of the package's interface as those parts designated by the author/maintainer, you have created a problem for maintenance of that package. Specifically, you have imposed an extreme constraint on its development. > I do not recall how I learned about IX approx 30 years ago. People learned about the original C standard I/O library's _doprnt() and _doscan() back in the day, too, and they used it. (Notoriously, curses did.) Why don't we see these symbols still in use today? Because they were _undocumented internal functions_. > maybe SunOS did have a ms manpage mentioning it... It did. `IX` was introduced in 4.2BSD. Here, I'll hand you a knife, but I'm going to take it away again. According to my greps, `IX` appears (in the macro summaries at the bottom of the page, as was typical in the 1980s) in the "ms.7" man pages of 4.2BSD, 4.3BSD, 4.3BSD-Reno, 4.4BSD, SunOS 2.0, SunOS 3.2, SunOS 3.5, SunOS 4.0, SunOS 4.1.4, and 2.11BSD. ("2.11BSD? What?"[1]) So, yeah, FACE, right? It was in the man page so it was official so groff should support it! Nay, _has to_ support it! No. A big ms-specific caveat enters now, and I take back the knife. groff ms doesn't support all 4.2BSD extensions to ms, and never has. I'll return to this momentarily in a more fortuitous place. There's a further caveat, at least as important. My greps included Solaris and Research Unix [v8-v10] (my records of both are incomplete but, I think, dispositive for this sort of question). And yet we do not see `IX` in either. Here's why. `IX` never made it back to Research Unix and Solaris dropped it outright, as they did _lots_ of stuff when they pivoted from a BSD foundation to System V). In fact, Research Unix implemented, presumably knowingly, an _incompatible_ macro, `P1`, using the same name as a 4.2BSD feature. (In further fact, 4.2BSD did it first! Compare V7's `CT` and `TM` with 4.2BSD's.) The implementation of `IX` that makeindex(1) desires (and illustrates in its man page) is also not consistent with the `IX` that we see defined in 4.2BSD ms. So an ms document author cannot rely on `IX` being portable, and has never been able to establish any such reliance. Well, except insofar as they felt the whole Unix world was BSD and SunOS and nothing else. Admittedly, there were once many such people. (They were obnoxious.) This is why I've carefully added annotations to the groff_ms(7) man page about which macros/registers/features are extensions, and whence they came (GNU, 4.2BSD, or Research Unix). To people who don't care about portability, maybe these seem like pointless asides. For those who do, I'm saving them a lot of time--the time you spent discovering the absence of `IX` in groff 1.23.0 multiplied several times over. > but as said in my first mail: if there is a useful undocumented > feature the solution obviously should be to document the feature > rather than removing it :). It's less obvious to me. Perhaps the foregoing complicated history of ms's name space begins to shed light on why. > also a short search brings up this document > > https://www.mail-archive.com/ion-general@lists.berlios.de/msg01838/ms.pdf > > (sure available elsewhere, too) Tell me if this looks familiar. https://git.savannah.gnu.org/cgit/groff.git/tree/doc/ms.ms?h=1.23.0 > which indeed at least mentions the IX macro. so it _was_ "user > visible" for groff 1.16 around 2004 (even if not "officially" > documented, maybe). Yes, sadly, Larry's excellent document kind of got lost for a while. It's back.[2] I'd urge you to peruse it in its new form, and inform this list (or the Savannah bug tracker) of any defects you find in it. > but as said "not documented" would not justify removal in the first > place). Certainly it won't do do remove everything that _isn't_ documented--that would leave us with a hollowed-out prototype, the sort of slide-deck-ware that one uses to bamboozle one's boss. Or customers.[3] > as said, I really do not really want to argue too much about the > issue, but... I posit that .IX is a "user macro", definitely not > intended for package "internal" use. I agree with that. It's obviously externally facing. > the question in my view is whether it is a good idea to delete an > apparently "unimportant", "useless", Just so the reader is clear, those two words are not quoting _me_ regarding this macro. Perhaps they reflect your view of a certain former ksh maintainer. ;-) > "undocumented" user macro from a central groff macro package like ms. Undocumented, it was. > so your line of thought in my view does at least not apply to .IX. It's important that we have a common understanding of what a macro package's interface is. If we lack that, we're unlikely to reach a meeting of the minds on a large number of more specific issues, like the fate of a particular macro. > s. above: there are (inofficial) documents listing it. While I reject any implication that _anyone_'s documentary exploration of package internals should bind a developer to supporting said internals, the case against `IX` is a little different. It has been documented in some places at some times, but is not portable. Given that one common solution to a macro's unportability is to define it oneself in a document, we find ourselves where you, in fact, ended up. > > I considered this. When contemplating how I'd write a paragraph > > specifying its behavior, I came to regard the macro as too simple > > and inflexible to be worth promoting to "official" status. > > the question remains: what harm is done if it is kept vs. how much > headache does removal cause in the field. Yes, and I think you and I have spent far more time composing emails discussing this question than document authors will spend fixing the issue for all time by pasting the erstwhile macro definition into their documents. It's not _great_, and I don't want to make such an imposition frivolously, but this problem did take over a year to surface. I don't know if that means that groff's ms(7) user base is small, that it's averse to complaint, or that the erstwhile `IX` macro simply didn't deliver anything of value to most people's documents. (The truth is likely some mixture of these in proportions I would like to know but probably never will.) > > > 2. regarding "no documents": well, maybe no "official" ones, but > > > mine sure did and those of other users probably too. :). > > > > This is the best argument against the change. Screwing up the > > rendering of real documents that people write and read is an > > anti-goal of mine. > > good! keep that goal :). Only one ms change is in the NEWS file for the forthcoming groff 1.24.0. * The s (ms) macro package now sets the vertical spacing register defaults for normal (`VS`) and footnote (`FVS`) text to 120% of the type size configured in the `PS` and `FPS` registers, respectively, rather than 2 points larger, to comport with generally accepted typesetting principles. Thus, when formatting a document with a type size of 20 points, the vertical spacing now defaults to 24 points rather than 22. From my perspective, interface-wise ms is pretty close to stable. I'd still kind of like to remove `RT`, but it's not a priority. I'd like to get its section heading macros using PDF bookmarks. Support for hyperlinks (within-document, and URLs) would be good too. > > But it's not the only objective I have for groff development. Some > > documents depend on (or work around) buggy behavior, and I think > > groff needs the freedom to fix its own bugs. > > the presence of .IX in ms is not a bug... Here's where we encounter a problem with your notion of absolute truth. Whether `IX` in fact _is_ present in ms depends on which ms implementation you're talking about, and what the date on the calendar is. And that remains true even if you ignore groff entirely. Moreover, it's true even ignoring groff _and_ historical developments. System V troff, somewhat to my disappointment, still isn't dead. > in fact ksh93 (the new korn shell maintained by Korn until about 10 > years ago) very fortunately now has a very dedicated and competent > maintainer > > https://github.com/ksh93/ksh > > (formally a fork from the now frozen official ATT repo) > > who goes to extreme length to not introduce breaking changes -- which > is a very important thing... I was vaguely aware of some amount of ruckus in the ksh community, mainly through intimations on the Austin Group mailing list. > will have to read that more thoroughly later. bookmarked. I hope it's less painful to read than it was to research. > > To get back to ms(7), I have considered withdrawing support for > > another undocumented macro, `RT`, for similar reasons as `IX`. Do > > you use that one? > > not that I can recall. I also do not find a definition in s.tmac? It's an alias. $ grep -w RT tmac/s.tmac .als RT LP .als RT @RT .als @RT par@finish And, yes, that's right, what it's an alias _of_ changes depending on what part of the document is being formatted. > > > I have now reimplemented the macro as a fix/workaround (it really > > > was a one-line macro in the orignal ms package anyway, I guess) > > > > Yes. This is the correct solution. In hindsight I should have > > added the macro definition I deleted to the release notes so that > > affected users wouldn't have to hunt it up. Neglecting to do so was > > a poor > > yes that would be principally desirable. but would not have helped me, > since looking at the release note was the very last thing I did (after > looking in vain for .IX in s.tmac... In an ideal world, people would read release notes before upgrading. In practice, people frequently upgrade blindly, and systems carry thousands of packages. Most of these are "infrastructure" on any given machine, not interfaces the operator uses directly, but, still, the number of packages fitting the latter category likely numbers in the dozens. So, if groff is something you care about and use directly, instead of just ignoring it as some mysterious thing that renders man pages, going to those release notes a.k.a. "NEWS" file is an important step when the major or minor version number increments. groff has these for the same reason any other software does. Things change. > > choice on my part. I apologize for that. I can't retroactively fix > > the release announcement, but I can update the NEWS file (in groff's > > source distribution) upon which that announcement was based; > > possibly some ms users will be spared the larger part of the > > frustration you suffered today. > > hopefully. but as said, the real problem is that "nobody expects the > spanish inquisition" > https://en.wikipedia.org/wiki/The_Spanish_Inquisition_(Monty_Python) > > not many people will think immediately "oh maybe the macro is no > longer part of the package" if a hickup occurs. not with ms being > functionally unmodified around for, what? >40 years or so. It changed from Sixth Edition (1975) to Seventh Edition (1979) Unix, got some incompatible changes in 4.2BSD (1982), further incompatible changes in Research Unix (~1986-1989), and then groff distilled a fusion of these into its own implementation around 1991. Eric Raymond added some macros in 2007, in part in an attempt to reconcile the BSD `P1` versus the Research Unix `P1` (and `P2`, upon which BSD had not stepped), and some further stuff he lumped into the category of "bell localisms" that he appears to have thought were _ms_ macros as opposed to document-local ones. Raymond's purpose, per his comments, seems to have been to get the Kernighan & Cherry eqn paper to format well with groff. I took Raymond's "bell localisms" out again in 2022, and tackled the problem of rendering the K&C eqn paper well as a separate project around the same time. https://github.com/g-branden-robinson/retypesetting-mathematics Raymond is not an assiduous researcher and has a notorious bent for self-promotion and other vices. Thomas Dickey documents behavior that sounds very much like plagiarism,[4] and Bruce Perens reported receiving a death threat from him.[5] In my view Raymond is an unreliable narrator on pretty much any subject. Regardless, or perhaps consequently, he does possess a sort of fan base. Then, in 2021, Keith Marshall added more stuff to the package.[6] > > "Necessary" is a strong word here. It wasn't "necessary". It was a > > choice. I believe I laid out the reasons for my choice at length > > above. > > your general approach/attitude, yes. why the .IX macro? I am not sure, > really, beyond that you personally do not find it useful (and I also > can admit to it's limited (but non-zero) usefulness ;)). No consistent interface. Whether your set of ms macros has it or not depends on its lineage, and as far as I know no troff has ever shipped anything on upon which `IX`'s output depends. To me, this veritably screams "let the user define it". > > Certainly. By the same token, the cost to your documents of a > > one-line definition is not high. (The cost was incurred in not > > initially being aware of the change, and the bug hunt that > > followed.) > > agreed. in this special case, yes. not much harm done (apart from time > burning). but as a general approach I really would prefer an extremely > conservative approach. In general, I think I am pretty conservative with packages' macro repertoires. But if a feature is not documented, or if it's buggy now and has been buggy forever, I take that as evidence that it never really landed, maybe never even was properly designed. Such things _should_ be subject to correction and revision. Or deletion. It may be my fate to die in battle with Hyrum's Law. > coming back to ksh: if you have time at your hand look at what > happened with ksh a couple of years ago when the official(!) ATT repo > was still under control of a maintainer who was intent on modifying > ksh beyond recognition ("improving" and "bug fixing" in his view :)). > the story can be found in the ATT ksh github repo in assorted > threads/issues. in my personal view ksh (and any ksh user) was > extremely fortunate that a) the ATT team came to a decision to freeze > the repo after rolling back to ksh93u+ (the last official ATT ksh93 > release) and b) https://github.com/ksh93/ksh happened afterwards. > otherwise ksh would have been done for I am sure. A summary from someone who wasn't a partisan in the dispute would be useful. Knowing nothing else about it, I suspect I'd find that there were some changes that were reasonable and others that were not. However, I also suspect that, once having transgressed into perceived disruptiveness and the number of critics reached a certain threshold, that said critics succumbed to a common temptation to "pad the brief", and characterize as disruptive changes that they would not have described thus before the threshold (or changes or of critics) was met. Unfortunately the Unix shell is not cleanly designed. But once people learn it, they find they can't ever wean themselves off of it. Numerous attempts to offer methadone to the Bourne junkies have failed. I admire Tom Duff's rc. Almost no one uses it. (I tried, twice. I shamefacedly shuffled back to Bash.) In fact the Unix shell may be one of the best examples of Hyrum's Law that exists. Sysadmins (we call them "site reliability engineers" now) find and exercise _every_ possible execution trace and then proclaim their scripts sacrosanct, no matter how ill-conceived they may be. So it's nearly impossible to unwind any blunder. zsh seems to have carried `SH_WORD_SPLIT` for approximately its entire lifetime, and I would guess there is no prospect of ever dropping it. > of course I honestly by *no means* imply that the situation with groff > is even remotely comparable. but the ksh story is a cautionary tale > what happens if backward compatibility is considered to be of > secondary relevance and things that used to work for a long time start > to break... Okay, it's a cautionary tale. I think the best guide to what groff should do is the presentation of concrete specimens. Deri hurled a large one at me last week (the UTP book reconstruction). I've learned some interesting things about it over the past few days, such that I'm not sure it's a good example of the sort of model document he intended it to serve as. But I'll return to those matters in a separate thread. > > And if you find that you need a fifth argument to `IX`, or to change > > the page numbering style under certain conditions, you will have > > more flexibility to do so. > > yes, sure. all true. but no reason to remove the thing in the first > place. of course I could redefine it. as it stands, it just was good > enough for my modest means more or less. I am not happy to have inconvenienced you, or to have surprised you by the means of doing so. > > My understanding of ms(7)'s audience and user base is that it is a > > package for *roff users who are willing to develop some > > sophistication with macro programming--meaning, you _may_ not need > > to write your own macros, but where you require a facility that the > > package doesn't offer, you're willing to start. mm(7) can be better > > for users who are more wary of macro programming--it provides > > numerous conveniences for those who are--and historical forces (the > > many divergent implementations of "man2html") have pushed man(7) in > > the opposite direction. I should probably have clarified this. By "opposite direction", I mean relative to "ms" rather than "mm". That is, we expect man(7) authors _not_ to define their own macros, and people like Ingo and me actively discourage it except as a last resort (perhaps for portability). > > Do you feel that characterization of audience describes you > > accurately? > > quite so (regarding ms at least -- mm I do not know anything about). > still, I really prefer to keep "extensions" beyond existing > functionality in ms at a minimum as far as possible. Do you mean in your own documents? That you try _not_ to define your own macros? If so, then I think that runs counter to how the package was envisioned and used at the Bell Labs CSRC. > _and_ I would hope for _keeping_ all existing functionality provided > in such a "legacy package" and avoid any break of backward > compatibility without very good reasons. The history of ms(7) is such that I feel this is impossible. Like make(1), it branched in multiple directions. Maybe groff ms(7) can, like POSIX 2024 make(1) promises to do, present a common subset that users find satisfactory.[7] At 2024-10-03T15:58:06+0200, joerg van den hoff wrote: > On 03.10.24 03:58, G. Branden Robinson wrote: > > If you had either of these enabled, or even just `-wmac`, you would > > have received a diagnostic during the build complaining of `IX` > > being undefined, which should have alerted you to the root cause of > > the issue. > > guilty as charged here. background: I usually at least do not actively > switch off warnings but in the driver script generating the documents > in question I did actually use -Ww simply because sometimes I want to > read the document in "nroff" mode and got _tons_ of spurious "cannot > switch to font XXX" warnings (spurious in the sense that those font > switches where meant for the pdf document and the warnings were, > although technically correct, totally irrelevant and interfered with > reading the doc onscreen). so not getting the ".IX unknown" warning is > indeed a consequence of this circumstance. As a general strategy when facing anything that's throwing lots of warnings at me, I try to get the ones that are most numerous sorted out first. For instance, consider the following change to the UTP 1.0 branch. commit bea74600bdb60809e523f22c34a2c0d9aa146086 Author: G. Branden Robinson <g.branden.robin...@gmail.com> Date: Tue Oct 8 02:17:09 2024 -0500 src/utp.mac: Use groff, not AT&T troff, font names Fixes numerous (1,000+) warnings of the following form: troff:./utp_ix.t:4034: warning: cannot select font 'CW' diff --git a/src/utp.mac b/src/utp.mac index ab40da9..b566fd8 100644 --- a/src/utp.mac +++ b/src/utp.mac @@ -10,6 +10,9 @@ book available again. Version of 16 November 2002 .. +.ftr C CR +.ftr CW CR +.ftr H HR .RT .nr nH 0 \" don't number [ABCD]-heads .nr gE 0 \" don't add chapter number to [ABCD]-heads Once those thousand-plus warnings were silenced, I was left with only about a dozen diagnostics to address. I found infelicitous table layouts, incorrect use of AWK, bogus register assignments, invalid delimiter usage in escape sequences, and a presumption about the arity of ms(7)'s `BX` macro that was assumed _and presented in the text_ but seems to have been true of _no_ ms(7), ever, that I can find. (Possibly the ms that O'Reilly used was a commercial version with an extension.) It's hard for me to regard a document with so many problems as a "golden master", but that is the role into which it seems to be getting drafted. > regarding default warning verbosity/frequency: I have noted that it > has increased considerably in recent groff release(es?) and I am > undecided whether I like or whether I hate it :). I confess abjectly to this. Improved input validation, clearer diagnostics, and corrected/expanded documentation have all been major themes of my contributions to groff since 2017. Adding, removing, or modifying features has been a minor one. That said, sometimes documenting things or illuminating invalid document or formatter state makes a behavior change, usually a minor one, seem desirable. Take this example from the UTP 1.0 branch. troff:./toc.t:69: warning: expected numeric expression, got character 'v' troff:./toc.t:131: warning: expected numeric expression, got character 'v' troff:./toc.t:195: warning: expected numeric expression, got character 'i' troff:./toc.t:255: warning: expected numeric expression, got character 'x' troff:./toc.t:323: warning: expected numeric expression, got character 'x' troff:./preface.t:150: warning: expected numeric expression, got character 'x' troff:./preface.t:372: warning: expected numeric expression, got character 'x' troff:./preface.t:531: warning: expected numeric expression, got character 'x' troff:./utp_book.t:20: warning: expected numeric expression, got character 'i' troff:./ch01.t:9: warning: expected numeric expression, got character 'i' This was an example of an `nr` request in two different "utp.mac" macros not working. In fact they never worked. They would never have worked in any *roff (unless some *roff somewhere implemented the decoding of roman numerals in its numeric expression parser, and I've never heard even a rumor of such a thing ever existing). I'm as sure as I can be that some people don't want to hear that their clever macrology isn't working as they intend, and never did. The best advice I can give them is to just shut off the warning, then. > let's just say: latex is not my friend in these regards. overall I > probably would prefer less default warnings and not too strict error > conditions. TeX is extremely garrulous even in regular operation. It's important to me to stick to one of the premises of the Unix command-line interface: No news is good news. If you get spew, any amount of spew, to the standard error stream from something that is designed as a filter (as *roff is), without enabling debugging output or something along those lines, then the system is trying to tell you that there is a problem, and you should pay attention. At least long enough to understand what it is you're silencing with `-W` or `-E`. > one example where this apparently has happened recently: mismatch > between file name and "internal" name of a font description file now > throws an error and the requested font is not used at all although > available (in my case I put a softlink into devps to augment some font > family by an italics font (since no such font was part of that font > family in the first place. in this way it was "documented" in the file > system at least what font actually was used. this used to work. but > recently (probably with 1.23) I have started to get that error and > refusal to switch to that perfectly fine italics font... I now, > therefore, had to cp the font and edit the internal name to make it > work again. so for me this is an example where I would deem the error > checking too strict. As I recall this change was discussed on this mailing list or in a Savannah ticket. It rings a Dave Kemper-shaped conversational bell. Ah, here it is. commit c0d1bb281908a6ed0b55d71cfc3c29b9750c29a2 Author: G. Branden Robinson <g.branden.robin...@gmail.com> Date: Fri Sep 17 15:55:26 2021 +1000 [libgroff]: Validate device, font files more. [libgroff]: Increase validation of device and font description files. * src/libs/libgroff/font.cpp (font::load): Validate the syntax and value of the `name` directive. (font::load_desc): Issue distinct diagnostics for a `fonts` directive that is missing arguments and for a first argument that can't be interpreted as a valid number. Hmm, no Savannah bug reference, though. Darn. Another hunt ensues... Found it pretty quickly! https://savannah.gnu.org/bugs/?61423 That's a 25-message exchange, so I won't quote it here. > > You may also find the `-b` option useful--it generates backtraces > > upon warnings or errors from the formatter. > > duly noted. thank you. It just proved its worth to me anew when chasing the UTP 1.0 issues. Regards, Branden [1] 2BSD has no clear chronological relationship with 3BSD and 4BSD. 2BSD was maintained as a sort of separate branch of BSD to backport to PDP-11 machines whatever could fit there, and was desired and regarded as feasible by its developers. It lives on quietly today, with something like 400 patches on top of its last official CSRG release. Given the tenor of your argument with me regarding groff, you don't want to know how conservative it is(n't) with respect to what gets tacked onto the system. ;-) [2] https://lists.gnu.org/archive/html/groff/2020-06/msg00044.html [3] https://builtin.com/hardware/vaporware [4] https://invisible-island.net/ncurses/ncurses-license.html [5] https://lists.debian.org/debian-user/1999/04/msg00623.html [6] https://git.savannah.gnu.org/cgit/groff.git/commit/?id=a50942f656386f04ec91be3e8813ab75fc56519f [7] https://gist.github.com/Earnestly/29deee4f18346da6630ed1df760f1590
signature.asc
Description: PGP signature
