Follow-up Comment #9, bug #66700 (group groff): At 2025-01-23T12:00:27-0500, Dave wrote: > Follow-up Comment #7, bug #66700 (group groff): > > Thanks for the quick diagnosis!
My pleasure! I like it when they're easy.
> [comment #1 comment #1:]
>> This may have been idiomatic, or nearly so, in AT&T troff.
>
> The new diagnostic is only a warning, and is off by default, and
> affects no output. So it's not breaking any compatibility. But if
> it's warning about something that _was_ once idiomatic,
I don't _know_ that. I wondered. I've never seen it anywhere else
before, in any macro package. But I saw that it wasn't a typo or
something arising from package author confusion (unlikely in Allman's
case). So I tried to reason what we was trying to do with this "invalid
syntax" and it didn't take long to figure out. There'd be cases were it
wasn't invalid, namely where the macro caller didn't bother to specify a
scaling unit.
> I wonder if it should get a NEWS item anyway, even though generally
> new diagnostics shouldn't be NEWSworthy.
I need more evidence that this truly was an idiom.
>> But I assume GNU troff's `;` operator exists for a good reason,
>
> This operator being a GNU extension, the proposed patch makes our -me
> package non-backwards-compatible. But maybe it already was? I
> thought I remembered a goal of keeping historical macro packages
> written in only AT&T syntax. But there may already be exceptions to
> that.
This is the only historical package that was freely licensed at the time
groff was written. And I think you're misremembering the goal.
Werner added the package's first usage of groff's `;` operator in commit
a977d802bd, 13 December 2000. But James Clark was using groff's `do`
request and other extensions a decade prior to that. Here's a sample of
the first commit in the repo.
+.\" Redefine the fam request to set the family in
+.\" environment 2 as well as the current environment.
+.if !\n(.g .ig
+.do rn fam @fam \" --- set family in current environment
+.do de fam \" *** set font family in ev 2 and current ev
+.do @fam \\$1
+.ev 2
+.do @fam \\$1
+.ev
+..
+.do ds _A \\n[.fam]
+.nr _I \\n(.i
+.ev \\$1
+.ps \\n(_S
+.vs \\n(_Vu
+.ft \\n(_F
+.do @fam \\*(_A
As I understand it, the goals with groff me were:
1. to preserve the BSD license on it; and
2. ensure the package worked in compatibility mode.
#2 was not a goal for groff ms; it's always used GNU troff extensions
unguardedly and warned of the fact in its documentation (or at least in
Larry Kollar's original ms.ms manual; I haven't checked Clark's man
page).
#2 is not an explicit goal for man(7) or mdoc(7) but the huge corpus of
documents prepared expecting AT&T troff tends to push us that direction.
On the other hand, with mdoc(7) there is the curious case of the `Bro`
and `Brc` macros. I've proposed renaming them, to a mild and copasetic
reaction from Ingo.
I suspect part of the idea was to make it easy for anyone wishing to
maintain the classic edition of me(7) to backport our changes. In some
places we even go out of our way to undertake tasks in two forms
depending on the value of register `.g`, one groffish and one in AT&T
style, but for some, that's not practical--what's a "font family" to
AT&T troff?--alternatively, we seem to rely simply on marking our use of
syntax and request repertoire extensions with `do`.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66700>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
