Re: [Groff] .ch request query]

[Dean Allen Provins]

************Forgot to put this on the mail list************

----- Forwarded message from Dean Allen Provins <address@hidden> -----

Ted:

Thanks for the clarification.  I must confess that I failed to read the
manual, and blithely assumed that if two macros were at the same trap
location, that I could get both executed when the trap was sprung.  It
see now that is not what happens.

Apparently I need to determine if a trap already exists at the desired
location, and then add a bit so that my macro will be executed
immediately afterwards.  I see no way of determining if another trap
already exists at that later location, which is unfortunate, but
probably will not be a problem in the general case.  The "ms" macros
which I use seem not to have too many traps preset, and surely I can
keep track of my own!

I suppose it might be nice if one could learn the name of the macro at
a desired trap location, and then "append" one's additional statements
to that macro, or alternatively indicate that the new trap (that which I
want to place at the pre-existing trap location) could be positioned 
immediately after the original trap.

I tried experimenting with positioning my macro immediately after a
pre-existing trap location, and found that the following seemed to
work, although curiously.  If "a_bit" has values or 0 <> 3, macro "y"
is executed.  For values 4 <> 7, macro "x" is executed and for vlaue 8,
both are executed.  It seems that if a trap is sprung, then adjacent
(later) traps are ignored as the line of macro text output sweeps past
the next trap position.

Have I interpreted this correctly?

Regards, and thanks for the help.

Dean

------------ms macro test----
.SH
title
.LP
.wh 2i x
.wh 3i y
.nr a_bit 8     \" try values 0 <> 8
.nr points ((\n[.t] + \n[.h]) / 1000 + \n[a_bit])
.ch y \n[points]p
.de x
.br
.nr where \\n[.h]
macro x was invoked at \\n[where]
Next trap is at \\n[.t]
.br
..
.de y
.br
.nr where \\n[.h]
macro y was invoked at \\n[where]
Next trap is at \\n[.t]
.br
..
.br
this is line 1
.br
this is line 2
.br
this is line 3
.br
this is line 4
.br
this is line 5
.br
this is line 6
.br
this is line 7
.br
this is line 8
------------end of test-------


On Wed, Aug 20, 2003 at 10:37:33PM +0100, Ted Harding wrote:
> On 20-Aug-03 Dean Allen Provins wrote:
> > Hello:
> > 
> > I had reason to place two traps at the same location, and as ".wh" at
> > the same place causes the second to overwrite the first (or so I
> > understood), I created the second at another trap location, and tried
> > to "move" it to the first.  This seemed not to work with groff version
> > 1.19.  Example code follows, and the postscript output is attached.
> 
> Hi Dean!
> 
> Nothing wrong with what you've done except that you've "understood" it
> the wrong way round (and very understandably: the way it really works
> is the opposite of what you'd intuitively expect, and it's confusing
> on first reading).
> 
> Quote from "Troff Users Manual" (section 7.5):
> 
>   "Two traps may be planted at the same position only by first planting
>    them at different positions and then moving one of the traps. The
>    _first planted_ trap will conceal the _second_ unless and until the
>    first one is moved (see Tutorial Examples). If the first one is moved
>    back, it again conceals the second trap."
> 
> The relevant Example seems to occur in the example section on footnotes,
> where there is code
> 
>   .wh 12i fo     \"footer trap -> temp pos
>   .wh -\\nbu fx  \"fx at footer position
>   .ch fo -\\nbu  \"conceal fx with fo
> 
> In this case the example fails to resolve an apparent ambiguity, since
> trap 'fo' is _both_ the first trap planted, and _also_ is moved to the
> position of the trap 'fx', so this could intuitively be interpreted as
> moving 'fo' "on top of" 'fx'. But according to the citation, it is the
> first planted trap which stays "on top" and, if the second planted one
> is moved to its position, then it is moved "underneath" the first!
> 
> The behaviour you observe (which also occurs with earlier versions of
> groff) is consistent with the interpretation I just gave (which I once
> had to suss out by trial and error!). In fact, "moving" is not "planting".
> 
> In other words: you plant trap 1 somewhere, and then trap 2 somewhere
> else. If you move 1 to the position of 2 then it goes "on top of" 2.
> If you move 2 to the position of 1 then it goes "underneath" 1.
> Motto: in case of conflict netween traps in the same position, the
> earliest trap planted anywhere is always on top, even if you have moved
> it.
> 
> In your code, reverse the order of planting 'x' and 'y', but still
> move 'y' to the position of 'x': you will see that you now get the
> macro "y" invoked, where you got "x" before.
> 
> (And you can test the general rule by defining a 3rd macro "z" like
> "x" and "y", and planting trap 'z' with
> 
>   .wh 4i z
> 
> Then no matter how you shuffle the order of
> 
>   .wh 2i x
>   .wh 3i y
>   .wh 4i z
> 
> and of
> 
>   .ch y 2i
>   .ch z 2i
> 
> it is always the earliest ".wh ..." which is "on top".)
> 
> Best wishes,
> Ted.
> 
> 
> --------------------------------------------------------------------
> E-Mail: (Ted Harding) <address@hidden>
> Fax-to-email: +44 (0)870 167 1972
> Date: 20-Aug-03                                       Time: 22:37:33
> ------------------------------ XFMail ------------------------------
> _______________________________________________
> Groff maillist  -  address@hidden
> http://ffii.org/mailman/listinfo/groff

-- 
                                Dean Provins 
                          address@hidden
                  KeyID at at pgpkeys.mit.edu:11371: 0x9643AE65