groff
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]