URL: <https://savannah.gnu.org/bugs/?68097>
Summary: [mm] change semantics of "presence-only" macros to
Boolean values
Group: GNU roff
Submitter: gbranden
Submitted: Fri 27 Feb 2026 06:00:31 AM UTC
Category: Macro package mm
Severity: 1 - Wish
Item Group: Feature change
Status: Postponed
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Unlocked
Planned Release: None
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: Fri 27 Feb 2026 06:00:31 AM UTC By: G. Branden Robinson <gbranden>
In comment 3 to bug #68059, I wrote:
> I don't think you misread the documentation so much as lack a view of the
> klunky interface contrived by the _mm_ package authors over the years of its
> development at AT&T's USG (and its successor organizations).
>
> Several _mm_ macros were written such that the mere _presence_ of a certain
> positional argument in a macro call determined behavior. This is easy to
> determine because one always has access to a macro call's argument count in
> the `.$` register.
>
> A _convention_ arose in _mm_ documentation that such "care-only-if-present"
> arguments were represented with a literal "1", which as you note, implies
> rather too much, like a Boolean value (but possibly some sort of magnitude),
[...]
> I've been nursing a long-term plan to migrate _groff_mm_(7) away from this
> slovenly documentary practice, and potentially to a strictly incompatible
> (but
> in practice, I suspect, not troublesome) yet more flexible practice of
> applying Boolean semantics to such arguments. (That approach would be more
> flexible because it is then easier to store the value you want to pass as
> the
> trailing argument to one of these _mm_ macros _in a register_ and then just
> interpolate it, instead of having to manage a string for the same purpose
> and
> keep careful track of whether it's empty or not.)
I would add that these new Boolean semantics would also make it possible for
_groff mm_ to extend the interface of such macros with further arguments in a
backward-compatible way; using these semantics, you could say "0" (or, since
this is *roff, a negative number) to retain a macro's default behavior in the
respect governed by that argument, while other arguments could still follow.
With the traditional semantics, this is impossible because even an empty
argument is "there" for the purpose of the argument count. So there's no way
tell _mm_ to ignore or skip over it.
> One of my _groff mm_ changes in 1.24.0 begins to clear a path for such a
> reform:
https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.24.0.rc4#n663
If this proposal doesn't meet with an eviscerating objection, I think as part
of this migration, I'd have macros that currently accept these "1" arguments
validate them for a numeric value, and start throwing warnings if they fail
that check. In a subsequent release, promote the warnings to errors.
Also, in documentation (the man page) we should replace the unhelpful,
meaningless "1" with a meaningful metasyntactical variable name. I've toyed
with the notion of suffixing these with question marks to reinforce their
Boolean semantics.
So, for example, the `ML` macro might change its synopsis from this:
ML mark [text‐indent [1]]
...to this.
ML mark [text‐indent [suppress-pre-item-space?]]
As we're in an increasingly icy freeze for the _groff_ 1.24 release, this
ticket is born postponed.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68097>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
