Issues with mm Macros

[Jeff Conrad]

Computer: Core-i7 6700, 32 GB RAM
OS: Windows 10 Pro, version 1803, 64 bit
Environment: MKS Toolkit, version 10.0
groff version: 1.22.3, Windows binary distribution

There seem to be a couple of bugs in the mm macro package (file m.tmac):

1.  According to the documentation (and long-established behavior), when
    register Pt=2, paragraphs are not supposed to be indented following
    a heading, list, or display.  Although paragraphs are not indented
    following a heading, they are indented following a list or display.

2.  If a list or display follows a heading, there is considerable extra
    vertical space between the heading and the list or display.

I just discovered these issues because for the last 20 years, I was
using a modified version of AT&T mm (which worked fine after I made sure
that requests were followed by whitespace; I may have had to make a few
other changes, but not many).

Paragraph Indention
-------------------
For the paragraph indention, the problem seems to arise because,
although the register address@hidden is set to zero, the P macro
only checks registers nl and .k against registers hd*last-pos and
hd*last-hsize to see if there has been any intervening vertical or
horizontal motion; the address@hidden is not checked.

One possible fix is to have the LE, address@hidden, and address@hidden macros 
set the
hd*... registers when the set address@hidden to zero, e.g.,

      .  .  .
    .nr hd*last-pos \\n[nl]
    .nr hd*last-hsize \\n[.k]
    .nr address@hidden 0
      .  .  .

Perhaps the registers could be renamed to ‘hld*...’ to indicate their
broader use.  I don’t know whether they should be considered “external,”
but if so, perhaps they should be renamed to address@hidden

Extra Vertical Space
--------------------
For the extra vertical space, the problem seems to result from the line

    \h'\\n[misc*.k]u'\c

near the end of the macro address@hidden, which is called at the end of macro
H.  This seems to generate something that is forced out when the br
request is given at the beginning of macro SP.

Offhand, I don’t have a fix.  To be honest, I don’t really understand
what is happening with the generation of HTML tags.  But—at least with
mm—the results I get from Thtml aren’t very good, so I’ve just commented
out the call to address@hidden  Although it solves my problem, it clearly
isn’t a general solution.

Jeff Conrad