man(7) .EE vertical spacing regression

[Ingo Schwarze]

Hi Branden,

the following commit caused a regression:

  commit 15f8188656ef0ebed797eb5981b012b590fc77ad
  Author: G. Branden Robinson <g.branden.robinson@gmail.com>
  Date:   Wed Feb 16 19:49:58 2022 +1100

    [man]: Refactor `EX` and `EE` macros.

Consider the following test file:

  .TH TEST 1
  .SH NAME
  test \- test
  .SH DESCRIPTION
  initial text
  .EX
  .EE
  .EE
  .PP
  final text

The problem is that starting with this commit, .EE does

  .rr an*saved-paragraph-distance

such that the second .EE now does

  .nr PD 0

whereas before the commit, it would have reused the value saved
by the previous .EX macro.  So before your commit, there was a blank
output line before the "final text" (as expected due to .PP) whereas
after your commit, that blank line is gone.

Admittedly, behaviour wasn't quite correct even before your commit.
For example,

  .SH DESCRIPTION
  initial text
  .EE
  .PP
  final text

never printed the blank line because without any prior .EX, .EE
resulted in .PD 0 anyway.  Also,

  .SH DESCRIPTION
  initial text
  .EX
  .EE
  .PD 2
  .EE
  .PP
  final text

was already mishandled before your commit because the second .EE
neutered the effect of the explicit .PD 2.

I think the bast way to fix all this is to make sure that .EE
only manipulates settings when an .EX block is actually open,
see the patch below.

As a regression fix patch, i intentionally kept the patch minimal
for review.  If you want, feel free to emit diagnostics in these
cases, which is likely easy.

i don't think it would make sense to support nesting of .EX blocks,
both because use cases for .EX do not require nesting and because
man(7) supports nesting for very few block macros anyway (.RS being
the notable exception).

What do you think?
Do you want to polish and commit it, or should i push it?

Yours,
  Ingo

P.S.:
After doing another "git pull", the number of new regression
failures in the mandoc test suite just went up from about half a
dozen to thirty-seven.  Most of those are probably due to intentional
changes in groff of vertical spacing around tbl(1) blocks.  Still,
i'll have to check whether these changes indeed *all* make sense.
So we are not exactly getting closer to a stable state that might
be good enough for release.  Then again, if we have given up hope of
releasing any time soon, that might not be a problem...


diff --git a/tmac/an.tmac b/tmac/an.tmac
index cf28fc3ce..fbc8cf845 100644
--- a/tmac/an.tmac
+++ b/tmac/an.tmac
@@ -986,11 +986,12 @@ contains unsupported escape sequence
 .
 .\" Begin an example (typically of source code or shell input).
 .de1 EX
+.  nf
+.  if ran*saved-font .return
 .  ds an*saved-family \\n[.fam]
 .  nr an*saved-font \\n[.f]
 .  nr an*saved-paragraph-distance \\n[PD]
 .  nr PD 1v
-.  nf
 .  \" If using the DVI output device, we have no constant-width fonts of
 .  \" bold weight and, relatedly, no constant-width family (because that
 .  \" requires all four styles).  Remap the bold styles to normal ones.
@@ -1006,6 +1007,8 @@ contains unsupported escape sequence
 .
 .\" End example.
 .de EE
+.  fi
+.  if !ran*saved-font .return
 .  \" Undo the remappings from `EX`.
 .  ie '\*[.T]'dvi' \{\
 .    ftr R
@@ -1016,7 +1019,6 @@ contains unsupported escape sequence
 .  fam \\*[an*saved-family]
 .  ft \\n[an*saved-font]
 .  nr PD \\n[an*saved-paragraph-distance]
-.  fi
 .  rr an*saved-paragraph-distance
 .  rr an*saved-font
 .  rm an*saved-family