Re: [Groff] Request "cf"

[Werner LEMBERG]

> 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