Re: .EM found missing

[Larry Kollar]

\G. Branden Robinson <g.branden.robinson@gmail.com> 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