[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: removing the .IX macro from the ms package in 1.23 breaks old docume
From: |
G. Branden Robinson |
Subject: |
Re: removing the .IX macro from the ms package in 1.23 breaks old documents |
Date: |
Tue, 8 Oct 2024 05:36:57 -0500 |
[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.robinson@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.robinson@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
- Re: Regressions in UTP document (was: removing the .IX macro from the ms package in 1.23 breaks old documents), (continued)
- Re: Regressions in UTP document (was: removing the .IX macro from the ms package in 1.23 breaks old documents), G. Branden Robinson, 2024/10/04
- Re: Regressions in UTP document (was: removing the .IX macro from the ms package in 1.23 breaks old documents), Deri, 2024/10/04
- Re: Regressions in UTP document (was: removing the .IX macro from the ms package in 1.23 breaks old documents), G. Branden Robinson, 2024/10/04
- Re: Regressions in UTP document (was: removing the .IX macro from the ms package in 1.23 breaks old documents), Dave Kemper, 2024/10/04
- when to deprecate and when to withdraw features (was: Regressions in UTP document), G. Branden Robinson, 2024/10/04
- Re: Regressions in UTP document (was: removing the .IX macro from the ms package in 1.23 breaks old documents), Deri, 2024/10/04
- blank pages in UTP document (was: Regressions in UTP document), G. Branden Robinson, 2024/10/04
- Re: blank pages in UTP document (was: Regressions in UTP document), G. Branden Robinson, 2024/10/04
- Re: blank pages in UTP document (was: Regressions in UTP document), Dave Kemper, 2024/10/07
- Re: Regressions in UTP document, G. Branden Robinson, 2024/10/08
Re: removing the .IX macro from the ms package in 1.23 breaks old documents,
G. Branden Robinson <=