Re: [bug #59573] typesetting.mom: traps are not initialised (set, planted)

[G. Branden Robinson]

Hi Peter!

Thanks for the swift follow-up!

At 2020-12-05T13:35:09-0500, Peter Schaffter wrote:
> On Sun, Dec 06, 2020, G. Branden Robinson wrote:
> >     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 don't think there is.  I was thinking only of the case where an
invalid .ch refers to an unplanted _undefined_ macro...which does _not_,
incidentally, cause a 'mac' warning.  (This is due to the mechanics of
how .ch implemented rather than any more principled reason, as far as I
can tell.)

I've reviewed div.cpp and as far as I can see there is no really
straightforward way to handle the other scenario, the one you're using
in mom.

Each diversion (including the top-level one, which is the one that's
relevant here) has a structure called a `page_trap_list` which,
naturally enough, contains a list of traps.  The problem is that macro
objects are only referenced by them in that one direction.  In other
words, there is no mechanism for querying a macro and asking it where
it's planted; there's no reverse linkage.

Moreover, even if we had one, which for language purposes would probably
look like an escape sequence which took a macro as an argument--to
interpolate the location of the macro-as-trap--there is a design
challenge in the implemention because as the new traps documentation
makes clear, it is legal for a given macro to be planted at multiple
locations.  That means having to represent or serialize a list in
interpolation form, and no *roff does that well.  For an example of an
attempt, see \n[.tabs].  And unlike \n[.tabs], what gets returned--in
the case of a multi-location trap--is not suitable for immediate usage
as a request argument.  On top of all that, a macro can be present at a
location but not "visible", because another trap at the same location is
"hiding" it.  Should that be listed or not?  If so, should its special
hidden status be indicated somehow?  It just feels squickier and
squickier the more I think about it, and I'm afraid if we fall down that
well we won't emerge before 2021.

> I'm in favour of reverting the change until we come to a consensus
> about its usefulness and how it's implemented.

:(  But you give me new hope below...

> This seems reasonable, given the current nop behaviour, which
> groffers expect.

*roffers in general!  I've been unable to find any differences between
Heirloom and groff in page location trap management.  Any implementation
deviating from both would face a considerable headwind.

> 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.

I like this, and would be happy to implement it.  I don't know if my
scruples will permit to add simply "and traps" to the description like
that, though experts will surely "know what is meant", but I think I
interpret your intentions.

> 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.

I either lacked imagination when implementing
e3b909eda11419daaf9e1ff028defc0e972ac827 or underestimated your
creativity in exercising dark corners of the *roff language design
space.  I apologize for that.

On the bright side, that means mom along with its examples is simply
_that much better_ of an integration test suite for groff!  :D

I invite further discussion (including seconds for your suggestion), but
if the lurkers remain quiet I intend to implement what you suggest in
the next few days.  I've marked Savannah #59573 as a blocker so we don't
accidentally release without addressing the matter.

Regards,
Branden

signature.asc
Description: PGP signature