Hi John, At 2024-02-28T07:26:21+1100, John Gardner wrote: > Hi Branden, > > Wouldn't this conflict with behaviour documented in groff_tmac(5)? From the > section *"Inclusion"* (emphasis mine):
Very much so, which is why I am submitting the proposal to this mailing list for feedback/assent/things I haven't thought of. Generally, I float "feature changes" (the name we have for them in Savannah) to the list before undertaking them. As I see it, these are things where we have to change existing documentation and/or update the NEWS file. Sometimes a change has a bugfix/behavior-change duality, and there is an observer effect. For example, here's a recent change I made to groff mm. NEWS: o The m (mm) macro package's `DS` macro now interprets its third argument (a right-hand indentation) in ens by default, for consistency with the rest of the package. This is a difference from DWB mm (which passed the value unprocessed to the `ll` request, which itself uses ems), and groff mm's own historical behavior, which used basic units. I figured that shifting from one AT&T incompatibility to a different incompatibility, but one which made the package more self-consistent (more so than DWB 3.3 mm itself was, in fact) would probably not get me dragged through the streets in chains. > I'm normally averse to changing documented behaviour without a > compelling motivation to do so; however, I admit that falling back on > tmac.s when s.tmac isn't found is rather unintuitive behaviour, and it > doesn't strike me as wise to mix modern Groff extensions with AT&T-era > warts. So I'm leaning tentatively in favour of this change. Cool. Thanks. I'll give it a few more days to percolate and gather objections, if any. Regards, Branden
signature.asc
Description: PGP signature
