\G. Branden Robinson <[email protected]> wrote: > > At 2020-11-15T14:13:38+0000, Dorai Sitaram via wrote: >> UTP strongly hints that the -ms macros have the end-of-input trap .em >> pre-set to a defined macro called .EM, with the implication that if >> the user wants to affect end-of-input behavior they can append or >> prepend to this macro rather than messing with .em directly. However >> groff's s.tmac sets its .em value to a macro of another name (viz., >> .pg@end-text). >> >> This is probably one place where one can safely bring back >> compatibility to earlier times. It is not necessary to give up >> .pg@end-text: .EM could either expand to or be an alias to >> .pg@end-text. I can't think of any modernizing rationale for groff >> to give up this convention. FWIW, both Heirloom and neatroff keep the >> .EM. > > It seems like a reasonable enough idea; would you file it as a New > Feaature item on Savannah?
Wait, wait… *checks s.tmac* Son of a gun. I could have sworn I used .EM in my ms-based macros back when, to print a back page. And it’s not documented in groff_ms(7), which is probably good since it’s not in the macros. Maybe I just used “.em Something” instead. Definitely fix this, please. I like the idea of aliasing to .pg@end-text, but looking at the code, it looks like pg@end-text calls pg@super-eject to flush keeps & footnotes. Perhaps, in the documentation, that we recommend using .am to add any further boilerplate content to EM/page@end-text to prevent unintended issues. — Larry
