[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Groff] .ch request query]
From: |
Dean Allen Provins |
Subject: |
Re: [Groff] .ch request query] |
Date: |
Thu, 21 Aug 2003 11:28:53 -0600 |
User-agent: |
Mutt/1.3.28i |
************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
- Re: [Groff] .ch request query],
Dean Allen Provins <=