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