Update of bug #68059 (group groff):
Severity: 3 - Normal => 4 - Important
Status: None => Confirmed
Assigned to: None => gbranden
_______________________________________________________
Follow-up Comment #3:
[comment #0 original submission:]
> According to groff_mm(7) the ML macro supports a third argument with which
> the vertical space before included list items can be suppressed.
Yes indeed.
> While this works as expected in groff 1.23.0:
> groff -Tutf8 -P-cbou -mm mwe-ml-svs.mm | cat -s
>
>
>
> This is an mm document with nested ML marked lists using
> vertical space suppression.
>
> Saturday
>
> □ Morning
> □ Noon
> □ Evening
>
> Sunday
>
> □ Morning
> □ Noon
> □ Evening
>
>
> the output of the same document produced with groff 1.24.0-rc3 differs in
> the following:
>
> * the pre-item space is still present
> * the list items are not indented
> groff -Tutf8 -P-cbou -mm mwe-ml-svs.mm | cat -s
>
>
>
> This is an mm document with nested ML marked lists using
> vertical space suppression.
>
> Saturday
>
> □ Morning
>
> □ Noon
>
> □ Evening
>
> Sunday
>
> □ Morning
>
> □ Noon
>
> □ Evening
That smells regressiony, all right. Confirmed on my machine, with an even
simpler reproducer. Bumping up severity as a regression from correct 1.23.0
behavior. Assigning to self as, once again, I'm surely the one to blame for
it.
> Possibly I misunderstand documentation, yet I'd expect that passing 0 as a
> third argument to ML would omit the vertical space suppression, which does
> not seem to be the case for neither groff 1.23.0 nor groff 1.24.0-rc3. I'm
> mentioning this here as it is somewhat related, if I misread the docs or a
> separate bug report is preferred, please let me know.
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), a
confusion compounded by the fact that, like all of the manful programming
languages developed by Bell Labs CSRC in the 1970s and 1980s, no human or
computer storage space was wasted on the silly notion of an explicit Boolean
data type. (If one really cared, one could pack Boolean values into C
bitfields. But most of the time, the pews were packed at the Holy Church of
the Machine Word As the Only True Data Type, with all other data types being
more or less distorted Catharite, cthnonic, ugly reflections of the shining
Platonic ideal of the machine register.)
It took until the 1990s for the languages invented by Dennis Ritchie and
Bjarne Stroustroup, C and C++ respectively--both men with a solid grasp of
digital logic that they unaccountably refused to apply here--to bend to an
elementary principle of data type hygiene that pays benefits in program
predictability and admitted automated verification of formal theorems about
program behavior--namely the admission (or construction) of data types that
can't take on undefined values. Pascal and Ada got there in the 1970s.
Possibly that is one reason C and C++ weenies professed to loathe them.
Undefined behavior is fun! And if it's not that, it might be job security.
Standard C's support for `enum` or explicitly-ranged integral types remains
pretty crap even in 2026, and last I checked C++ isn't much better. But at
least they admitted the limiting case of `bool` in their 1999 and 1998
standards, respectively. With Ritchie, it seems certain, blowing a raspberry
as illustrated in the foreword to _The Unix-Haters' Handbook_ the entire
time.
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.)
One of my _groff mm_ changes in 1.24.0 begins to clear a path for such a
reform:
NEWS:
* The m (mm) macro package's `LI` macro now interprets its second
argument as a Boolean value indicating whether a space should
separate the list item mark from its prefix (the first argument).
Thus, where you formerly specified "2" to indicate no such
separation, you would now use "0", matching the semantics of the
former `Limsp` register. "2" continues to be recognized and handled
as before, but prompts a warning; migrate your documents.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68059>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
