As a troff guy from the 1980's, I still have the docs that the computer science department at UW Madison put in my hands. I just love that people are trying to make troff better. Larry rocks.
I wish more people knew this. On Mon, Nov 23, 2020 at 09:55:17PM -0500, Larry Kollar wrote: > > \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 -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
