[bug #59290] ms: add register to enable backtraces on diagnostics

[G. Branden Robinson]

URL:
  <https://savannah.gnu.org/bugs/?59290>

                 Summary: ms: add register to enable backtraces on diagnostics
                 Project: GNU troff
            Submitted by: gbranden
            Submitted on: Sat 17 Oct 2020 10:21:00 PM UTC
                Category: Macro - ms
                Severity: 1 - Wish
              Item Group: New feature
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

I'm about to close bug#55109 but its heart is in the right place.

I don't think spewing the name of the macro that emits every diagnostic is a
good first-order remedy for problems.  Why would the user care about the name
of the macro?

It's easy to see why the submitter reached for that tool, however; GNU ms's
diagnostics, while immeasurably more generous and helpful than AT&T ms's,
plainly leave a lot to be desired in the rather common case when a user inputs
a macro that opens a diversion and then EOF is seen.  Here's a trivial
example:


$ groff -z -ms
.TL
:0: macro error: diversion open while ejecting page (recovering)


This seems almost indecipherable.  There are four problems as I count them.

1. The macro package doesn't prefix all diagnostics with its own name.

2. After the end of input, \n[.F] is empty.  ms doesn't check that before
emitting a diagnostic, leading to the first ":".

3. After the end of input, \n[.c] is zero.  ms doesn't check that before
emitting a diagnostic, leading to "0:".

4. If ms is being run as part of some build process, you don't know what the
last file it processed was when the diagnostic was emitted.  Terribly
unhelpful.  Only an error exit status could possibly save you, and ms doesn't
cause troff to exit nonzero in this case.

So you're pretty deeply hosed.  How many people has this turned off over the
years, I ask myself with a sense of dread.

I have a fix for the first three problems, but all that's more of a bug #55109
discussion.

It did occur to me, however, the backtracey stuff might be useful for someone
needing to really dig in.  If only we had useful backtraces...

In groff 1.23, we will.  See bug#58153.

So I propose an opt-in number register that the user can set.  If it's truthy
when a diagnostic is emitted, call .backtrace.

This is really easy to implement.  The hard part is what to call the register.
 Maybe just BACKTRACE?

Then we'd have:


.        if \\n[BACKTRACE] .backtrace





    _______________________________________________________

Reply to this item at:

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

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