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
