[bug #61070] [troff] want to drop default "User Abort." text from .ab request

[G. Branden Robinson]

Follow-up Comment #3, bug #61070 (project groff):


[comment #2 comment #2:]
> Even in its most back-compatible mode (-x0), Heirloom troff gives some
useful information when .ab is called with no argument

Yes, quite a bit of it.

> (though it also exits with a 0 status).

Yikes!
 

> Whether that's evidence that AT&T troff's bare .ab was a bit more chatty,

Version 7 Unix troff definitely was not.

https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/troff/n5.c

(You'll have to search the text, as minnie doesn't show line numbers.)

> or that Heirloom's implementers didn't consider historical .ab output
sacrosanct, I cannot say

I think it's clear that they didn't.  V10 Research Unix didn't change much,
possibly taking off the period.

https://minnie.tuhs.org/cgi-bin/utree.pl?file=V10/cmd/troff/n5.c

DWB 3.3 troff is unchanged in this respect from V10.

https://github.com/n-t-roff/DWB3.3/blob/master/text/troff/n5.c#L435

> -- but I think either one makes the case that we needn't be married to the
output groff's .ab currently offers.

So it seems.

> So "make groff stderr output match Heirloom's" could be yet another option,
maybe D1.

Yeah, but I'm leaning away from it.  I kind of want an .ab that is quiet by
default.

> B1 and B2 are my least favorites: they add a new request that offers no real
new functionality, just tweaks functionality offered by an existing request;
and the request they add will be interpreted by strictly conforming historical
implementations as ".ab" with the argument "ort" anyway.

Good point.

> But that's all on purely theoretical grounds; I've never had occasion to use
.ab in real life, so I don't have any strong opinion about how it works.

I was going to say that it shows up with some frequency in groff's macro
packages, but most or all of the cases I see, I had a hand in writing.  Oops.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61070>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/