Re: .ab oddity

[G. Branden Robinson]

Hi Peter,

At 2023-02-03T15:11:05-0500, Peter Schaffter wrote:
> Before I file a bug report, I'm wondering if this is unique to me.
> 
>   echo ".ab" | groff -Tutf8
> 
> does not print "User abort".  (".ab foo" correctly prints "foo".)
> 
> My current build is 1.23.0.rc1.3711-25fb.

It is not unique to you, and it is deliberate.  I felt it was
unorthogonal for `ab` to force a message onto the standard error stream
when the `tm` request (and groff's several relatives of it) already
existed.[1]

Part of the idea here is that you can then use `am` to stick an abort
request onto any other macro, perhaps one which already produced a
perfectly diagnostic message, without having to just through any hoops.

It also aligns better with `nx` and `ex` this way.  One might call any
of these to (in `nx`'s case, potentially) get out of the program.

The NEWS file documents this change (and some example applications).

--snip--
o The `ab` request no longer writes "User Abort." to the standard error
  stream if given no arguments.

o The `PDFPIC` macro (provided by the `pdfpic` package) no longer aborts
  upon encountering trouble.  Instead, it reports an error and abandons
  processing of its argument(s).  It is also more sensitive to other
  kinds of problems and handles them the same way, by issuing a
  diagnostic and returning.  If you wish `PDFPIC` to abort document
  processing immediately upon error, you can append an `ab` request to
  the package's error-handling macro.

    .am pdfpic@error
    .  ab
    ..

o The pspic package now also has an error hook macro, which you can use
  to make failed image loads fatal (or attempt fallback or recovery).

    .am pspic@error-hook
    .  ab
    ..
--end snip--

Regards,
Branden

[1] There I go again, brazenly challenging the infallible wisdom of
    Murray Hill.  ;-)

signature.asc
Description: PGP signature