> Thank you for your post. It works like charm and, since it only
> generates 1 pair of EBEGIN-EEND, it is much more preferable to my
> current scheme.
>
> However, one problem: I have no idea how it works, and I am sure
> that this would also be the case with other Mr Average Users. First
> I thought that the secret was in .da, in appending, and tried to
> simplify your case by moving things out of the macro (Scheme 3 in
> the schemes.pdf file). Yep, it is ok with asciihex, but not with
> ascii85. The secret of avoiding ‘cooking’ is not (only) in using
> .da.
You might read section 5.32, `gtroff internals', in the info manual
for some background information.
Both macros and diversions use the same object to store the data;
however, macro data is stored unprocessed, diversion data is stored
processed. The data in `before' and `after' are unprocessed; you have
manual control so that a backslash character can be input as `\\'.
However, you can't double backslashes in the data read in with `.trf',
so its contents must be stored without further processing -- `.da'
does this, because `.trf' completely bypasses groff's data processing
mechanism.
Theoretically, I could do the same with
.eo
<data with single backslashes>
.ec
However, we want to read in the data with
.eo
\\*[stuff-stored-in-a-diversion]
.ec
and this fails -- `\\*' doesn't get expanded. In TeX, I could use the
\expandafter command to delay the effect of `.eo', but in groff this
isn't possible.
> Another thing: it is also a three-part series, not very simple. The
> auxiliary macro disrupts the flow of PS from <pre> to <post> more
> than a single \\*[something] would.
With the current possibilities in groff, this is unavoidable (because
we have to change between .da and .am).
> Werner, could you please explain [...] why scheme 3 fails. I
> certainly don’t know a lot of facts that would enable me to
> experiment with a chance of success.
I hope the above answers this: You can't expand \\*[buffer] in general
while defining a macro.
> If you could manage avoiding ‘cooking’ with a a ’one-part series’
> (Schemes 3 and 4), that would be GREAT. Then I would not even mind
> if I could not understand its working :-)
Hehe. This would need a new command in groff, and I'm not sure
whether it's worth the trouble.
> I am just curious about the placing of .br after the buffer macro.
> Does it have to compensate for some side-effect of the macro or it
> is just there by ‘accident’?
The `.br' is here to emit the `current partial input line' before
collecting data in the diversion. This is standard diversion
behaviour. See the description of the `.box' request in the info
manual for a description.
Werner
