Re: .EM found missing

[Larry McVoy]

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 <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

-- 
---
Larry McVoy                  lm at mcvoy.com             
http://www.mcvoy.com/lm