Proposed GNU troff behavior change: require end-of-input macros to exit

[G. Branden Robinson]

Hi folks,

I have a *roff language reform to suggest.

I propose that GNU troff stop behaving like AT&T troff in one aspect of
end-of-input macro processing, documented in our Texinfo manual.

 -- Request: .em macro
     Set a trap at the end of input.  MACRO is executed after the last
     line of the input file has been processed.

     For example, if the document had to have a section at the bottom of
     the last page for someone to approve it, the 'em' request could be
     used.

          .de approval
          \c
          .  ne 3v
          .  sp (\\n[.t]u - 3v)
          .  in +4i
          .  lc _
          .  br
          Approved:\t\a
          .  sp
          Date:\t\t\a
          ..
          .
          .em approval

     The '\c' in the above example needs explanation.  For historical
     reasons (and for compatibility with AT&T 'troff'), the end macro
     exits as soon as it causes a page break and no remaining data is in
     the partially collected line.

     Let us assume that there is no '\c' in the above 'approval' macro,
     and that the page is full and has been ended with, say, a 'br'
     request.  The 'ne' request now causes the start of a new page,
     which in turn makes 'troff' exit immediately for the reasons just
     described.  In most situations this is not intended.

     To always force processing the whole end macro independently of
     this behaviour it is thus advisable to insert something that starts
     an empty partially filled line ('\c') whenever there is a chance
     that a page break can happen.  In the above example, the call of
     the 'ne' request assures that the remaining code stays on the same
     page, so we have to insert '\c' only once.

The AT&T-compatible behavior surprises people over and over again.  It
bit Jörgen Hägg when he implemented GNU mm, for example; see
<https://savannah.gnu.org/bugs/index.php?64336>.  This bug lingered for
over 30 years.

Dave Kemper pointed out that a similar idea, a new `em1` request to
behave this way, was mooted on this list in 2009...but the code never
landed.  See <https://savannah.gnu.org/bugs/index.php?64986>.

I would prefer to just make `em` behave the way people expect, but
retain the weird old behavior for the benefit of historical documents.

Keeping the `\c` in an end-of-input macro, or a macro called by an
end-of-input macro, should not behave any differently.  It _could_
cause a spurious blank page at the end of the document--that's kind of
what it's there for, to keep the formatter from exiting before the
end-of-input macro is "ready", but this would always have been the case.
A person targeting GNU troff alone could leave out the `\c` escape
sequences, and waste no paper.

CSTR #54 in its 1992 revision _did_ warn of this behavior: ", but all
processing ceases at the next page eject." (§7.5).  CSTR #54 1976 and
1981 did _not_ say this.  I conjecture that this was a concession to a
bug that looked too hard to fix.  Whatever the reason, I would document
this as a behavioral difference between GNU and AT&T troffs.

I'm tracking the development of this feature change in
<https://savannah.gnu.org/bugs/?64582>.

Thoughts?

Regards,
Branden

signature.asc
Description: PGP signature