[bug #60590] [mdoc] all vertical spacing disappears during particular batch processing

[G. Branden Robinson]

URL:
  <https://savannah.gnu.org/bugs/?60590>

                 Summary: [mdoc] all vertical spacing disappears during
particular batch processing
                 Project: GNU troff
            Submitted by: gbranden
            Submitted on: Wed 12 May 2021 08:28:10 AM UTC
                Category: Macro - mdoc
                Severity: 3 - Normal
              Item Group: Incorrect behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

This is the second of two weirdnesses mentioned in bug #60589.

The scenario is batch man page processing using andoc.tmac.

One of my regression testing techniques turned it up.

Try the following after copying all of the build-generated groff man page
sources into a directory.


../build/test-groff -dAD=l -rCHECKSTYLE=1 -Tutf8 -e -t -mandoc addftinfo.1
afmtodit.1 chem.1 ditroff.7 eqn.1 eqn2graph.1 gdiffmk.1 glilypond.1 gperl.1
gpinyin.1 grap2graph.1 grn.1 grodvi.1 groff.1 groff.7 groff_char.7
groff_diff.7 groff_filenames.5 groff_font.5 groff_hdtbl.7 groff_man.7
groff_man_style.7 groff_mdoc.7 groff_me.7 groff_mm.7 groff_mmse.7 groff_mom.7
groff_ms.7 groff_out.5 groff_rfc1345.7 groff_tmac.5 groff_trace.7 groff_www.7
grog.1 grohtml.1 grolbp.1 grolj4.1 gropdf.1 grops.1 grotty.1 gxditview.1
hpftodit.1 indxbib.1 lj4_font.5 lkbib.1 lookbib.1 mmroff.1 neqn.1 nroff.1
pdfmom.1 pdfroff.1 pfbtops.1 pic.1 pic2graph.1 preconv.1 refer.1 roff.7
soelim.1 tbl.1 tfmtodit.1 troff.1 xtotroff.1


The pages mostly render fine, except for groff_mdoc(7), which is missing blank
lines everywhere there should be one.

This misbehavior sprang to life after commit
376a07c8e4c10e11364df60259f5d03a271f0515 (which I haven't pushed yet as of
this writing).  I'll end up pushing it anyway because there's no way it should
have been responsible for this.


commit 376a07c8e4c10e11364df60259f5d03a271f0515
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Tue May 11 12:53:58 2021 +1000

    groff(7): Relocate material.
    
    General statements about the escape sequence name space are better
    placed before the exhaustive list than after it.

diff --git a/man/groff.7.man b/man/groff.7.man
index c9d12e97..c589a0da 100644
--- a/man/groff.7.man
+++ b/man/groff.7.man
@@ -3048,6 +3048,36 @@ alternative facilities it provides to achieve the
desired result.
 .SS "Escape short reference"
 .\" ====================================================================
 .
+The escape sequences
+.esc e ,
+.esc . ,
+.esc \[dq] ,
+.esc $ ,
+.esc * ,
+.esc a ,
+.esc n ,
+.esc t ,
+.esc g ,
+and
+.escarg \& newline
+are interpreted even in copy mode.
+.
+.
+.P
+Escape sequences starting with
+.esc (
+or
+.esc [
+do not represent single character escape sequences, but introduce escape
+names with two or more characters.
+.
+.
+.P
+If a backslash is followed by a character that does not constitute a
+defined escape sequence, the backslash is silently ignored and the
+character maps to itself.
+.
+.
 .PD 0
 .
 .\" ========= comments =========
@@ -3711,37 +3741,7 @@ and then restore the horizontal and vertical position;
 .I anything
 may not contain tabs or leaders.
 .
-.
 .PD
-.P
-The escape sequences
-.esc e ,
-.esc . ,
-.esc \[dq] ,
-.esc $ ,
-.esc * ,
-.esc a ,
-.esc n ,
-.esc t ,
-.esc g ,
-and
-.escarg \& newline
-are interpreted in copy mode.
-.
-.
-.P
-Escape sequences starting with
-.esc (
-or
-.esc [
-do not represent single character escape sequences, but introduce escape
-names with two or more characters.
-.
-.
-.P
-If a backslash is followed by a character that does not constitute a
-defined escape sequence, the backslash is silently ignored and the
-character maps to itself.
 .
 .
 .\" ====================================================================


groff(7) is the only one of our man pages that uses the .PD macro we
deprecate.  You will notice that it appears in the context of this diff, but
no .PD calls were added or removed.

And yet .PD has something to do with it, because if I _delete_ that macro call
(this is last of several in the page), then it wrecks the paragraph distance
for the rest of that page, as we would expect.  The correct paragraph distance
is restored in the subsequent man(7) page, _and_ in groff_mdoc(7), several
page sources later.  Extra bizarre: our mdoc(7) implementation does not use a
register named PD in any way.

Catting all these pages together into one giant source document does not
change the behavior, so at least there's nothing about file opening and
closing that seems to matter.

Trying to narrow down the problem by binary search has proven difficult; I can
remove all the man pages in the list above _after_ groff_mdoc(7) without
altering the output (apart from the later pages not being rendered, of
course), but taking out various subsets of the other pages brings
groff_mdoc(7)'s blank lines back.  Get rid of all the pages between groff(7)
and groff_mdoc(7)?  This problem vanishes.  Get rid of addftinfo(1), at the
head of the list before any of this .PD call nonsense?  This problem
vanishes.

Remember when I said "Get rid of all the pages between groff(7) and
groff_mdoc(7)?  This problem vanishes."

Another one shows up.  The \[oq] and \[cq] glyphs which later show up in
groff_out(5) and gropdf(1) are suddenly italicized.  And the ones in pdfmom(1)
disappear.

Deeeeeeeeply mystifying.




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60590>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/