[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #59290] ms: add register to enable backtraces on diagnostics
From: |
G. Branden Robinson |
Subject: |
[bug #59290] ms: add register to enable backtraces on diagnostics |
Date: |
Sat, 17 Oct 2020 18:21:02 -0400 (EDT) |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 |
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/
- [bug #59290] ms: add register to enable backtraces on diagnostics,
G. Branden Robinson <=