Hi Deri, At 2025-07-05T16:25:07+0100, Deri wrote: > On Friday, 4 July 2025 23:49:01 BST G. Branden Robinson wrote: > > > 3) the number has too many (irrelevant) digits. > > > > groff is written in C++. We don't have a numeric tower including > > rationals. > > I thought C++ had snprintf to handle rounding to a fixed number of > decimal digits?
Yes, but loss of precision is frequent. > What is the purpose of the reference to rational numbers in this > context? Because as far as I know, irrational numbers are never used for any measurement operations in groff. (They, too, are not readily modeled in C++ if one confines oneself to the language standard.) Everything's rational, and that means that the most economical, perfectly precise, and frequently most intuitive way to represent these values is by the ratio that existed prior to conversion to decimal floating point. (One might want that ratio reduced to lowest terms.) Unfortunately it seems kind of hard to get there from here. > > I don't have trouble understanding that "less than one one-hundredth > > of an inch" is an almost negligbly small number. With sufficient > > demand we could add a feature that suppresses these messages below a > > certain threshold. > > That is a good idea, you might consider suggesting a specific .tkf > command which would get rid of the message for such very small > numbers. Yes, `tkf` is probably under-utilized--I haven't used it much myself. (See <https://savannah.gnu.org/bugs/?62060>.) When musing about the complaint Bjarni made, I also considered that we could add a second argument to `warnscale` that would set a threshold below which the user doesn't care about over- or underset. > The issue is about the abundance of decimals for lines which overset > by a very small margin. Is there really an abundance? I see a handful when doing groff builds, but only when doing a "make distcheck" because we end up with some whopping huge file specifications (for boring reasons).[1] Here they are, in context: troff: backtrace: file 'tmac/groff_mdoc.7':5272 troff:tmac/groff_mdoc.7:5272: warning [page 316, 2.1i]: cannot adjust line; underset by 0.716944i troff: backtrace: 'an.tmac':949: macro 'IR' troff: backtrace: file 'contrib/mm/groff_mm.7':358 troff:contrib/mm/groff_mm.7:358: warning [page 324, 1.8i]: cannot adjust line; underset by 0.80125i troff: backtrace: 'an.tmac':949: macro 'IR' troff: backtrace: file 'contrib/mm/groff_mm.7':2826 troff:contrib/mm/groff_mm.7:2826: warning [page 333, 9.1i]: cannot adjust line; underset by 0.00652778i In a "normal" groff build, I don't see _any_. They can be shut off with `-Wbreak` if they're offensive. > You may not agree with the suggested fixes to the issue, One person suggested _one_ fix, and it was impractical for the reason I stated--except on terminals, which _already_ report over- and underset in units of ens, and in integral amounts to boot! (This is a new thing for the forthcoming groff 1.24.) Here's the same "distcheck" document getting formatted for the terminal. troff: backtrace: 'an.tmac':763: macro 'I' troff: backtrace: file 'contrib/mm/groff_mm.7':362 troff:contrib/mm/groff_mm.7:362: warning [page 1, line 22263]: cannot adjust line; underset by 5n troff: backtrace: file 'contrib/mm/groff_mm.7':1188 troff:contrib/mm/groff_mm.7:1188: warning [page 1, line 22499]: cannot adjust line; underset by 1n troff: backtrace: file 'contrib/mm/groff_mm.7':2827 troff:contrib/mm/groff_mm.7:2827: warning [page 1, line 22999]: cannot adjust line; underset by 3n (There are more of these, maybe 2 dozen total. What do these lines look like? Well, thanks to the "infinite page length" feature also new to the forthcoming groff 1.24, the location reported by this sort of diagnostic actually means something even in nroff mode and is useful. $ sed -n '22262,22264p' build/groff-1.23.0.3493-3addc/_build/sub/doc/groff-man-pages.utf8.txt to be loaded at package initialization. If this mechanism is not used, /home/branden/src/GIT/groff/build/groff-1.23.0.3493-3addc/_inst/share/ groff/1.23.0/tmac/mm/locale is loaded instead. No diagnostic is produced Adjustment was enabled, but there are no adjustable spaces on that line, hence the warning.) > but it is probably better not to be so "brusque" with people whose > intent is to improve groff. I don't think dismissal of an _idea_, even brusquely, constitutes a personal attack or unfair comment. (If you think I have made either of these, please bring the fact to my attention, as I think such things unwarranted in technical discussion.) Bjarni has a long-established track record of being hasty with bug reports. Ingo proposed rejecting _all_ of his ticket submissions on Savannah for this and other reasons. I disagreed; I think some of Bjarni's reports are worthwhile and actionable, and others aren't.[2] Like everyone else who contributes (I hope), he gets credited in change logs, commit messages, and the "ANNOUNCE" file. We all have bad ideas from time to time. You've pointed out one or two (or more) of mine in terms one might call "brusque". ;-) To sum up, I think we have better things to do than tone policing. That is too often the refuge of those find themselves unable to marshal substantive arguments against a proposal, or worse, who recognize a sound proposal but wish to torpedo it for reasons they refuse to disclose, like a conflict of interest or ethically compromised position. You can, of course, disagree, and chide me again in the future. Regards, Branden [1] The boring reason is that "distcheck" saddles us with a "DESTDIR" along the lines of "/home/branden/src/GIT/groff/build/groff-1.23.0.3493-3addc/_inst/", which blows out the file specifications listed in our man pages. [2] I can say the same of myself. For sport, one can do a search our Savannah ticket tracker for issues that were submitted by me and also closed by me, with status "Rejected".
signature.asc
Description: PGP signature
