[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #59573] typesetting.mom: traps are not initialised (set, plante
From: |
Peter Schaffter |
Subject: |
Re: [bug #59573] typesetting.mom: traps are not initialised (set, planted) |
Date: |
Sat, 5 Dec 2020 13:35:09 -0500 |
User-agent: |
Mutt/1.9.4 (2018-02-28) |
On Sun, Dec 06, 2020, G. Branden Robinson wrote:
> [redirecting to groff@ for discussion]
>
> Background: In https://savannah.gnu.org/bugs/index.php?59573, Bjarni
> pointed out that a recent change I made caused some diagnostics to
> appear.
> > troff: ../contrib/mom/examples/typesetting.mom:638: error: cannot move
> > unplanted trap macro 'FN_OVERFLOW_TRAP'
> As noted in my commit message, I thought--admittedly based on
> little but my own instincts and meager experience as a *roff
> author compared to you--that it would be more helpful to aler the
> user when they were doing something that "looked like" it should
> do some work, but didn't really. What approach best suits the
> user base?
>
> 1. Revert the change, possibly telling users in the manual how
> write their own validity-testing wrapper for .ch.
What would such a wrapper look like? I am unaware of how to test
for whether a trap has been set other than .ptr, which prints to
stderr.
I'm in favour of reverting the change until we come to a consensus
about its usefulness and how it's implemented.
> 2. Postpone the change for after the 1.23.0 release but advise
> of it in the release notes as planned subsequently, so people
> have time to adapt.
Not fond of this one.
> 3. Downgrade the error to a warning.
This seems reasonable, given the current nop behaviour, which
groffers expect. It is useful for debugging to know a trap hasn't
been planted, but, like an undefined string, it should be treated as
a warning.
> This will require determine an appropriate warning category for
> it.
I'd recommend mac (.warn 512), and update the description of mac
in troff(1) and elsewhere to "Use of undefined strings, macros,
diversions, and traps." My reasoning is that .ch "uses" a trap,
hence the absence of that trap means you're using something
undefined.
A warning alerts you to a potential problem and allows
you to do something about it if necessary; an error is just plain
wrong and has to be fixed. The .ch problem is of the first
category and should be treated as such.
--
Peter Schaffter
https://www.schaffter.ca