Re: [Groff] soelim and file names defined in string registers

[Ted Harding]

On 18-Aug-06 Joerg van den Hoff wrote:
> [...]
> Ted,
> 
> it does, thanks a lot. I see the problem now: `soelim' (which
> is the first preprocessor called anyway) silently ignores the
> `.so' request including the string register and that's why the
> `.so' survives until troff gets into gear after the other
> preprocessors, right?

The real problem there is the converse of the other problem

Since 'soelim' is a pre-processor, it is run before 'troff'
sees the file. So at that stage, the form of the request (as
seen by 'soelim') is

.so \*[fname]

since troff has not yet had a chance to define the string!
Since there is no file "\*[fname]" (I dare say), 'soelim'
will not have anything to work with. So it is not that it
"silently ignores" the request -- rather, it executes it
and finds nothing there.

> thanks, too, for the workaround. I will think about it
> (also running "unsafe" is not always desirable ...).

Not always, perhaps, but depending on your environment
it may nearly always be perfectly safe!

The normal dependency on pre-processers, while allowing a
wide range of sophisticated work to be done, does require
you to keep in mind what parts of the file have been seen,
and what parts not seen, by the various components of a
'groff' pipeline, at any stage of the processing.

I have sometimes (slightly mad idea ... ) considered (at
least experimentally) re-writing relevant macros such as
".PS/.PE", ".TS/.TE", ".EQ/.EN" so that they automatically
write out what occurs between the start and end to a file,
run the appropriate "preprocessor" program on the file,
and read the output back in (on the lines of the work-round
I described). In this way, the "preprocessor" aspect would
disappear and in effect 'troff' would process each such
block of special code as if it had the resource built-in
to itself (albeit in fact forking an external program to
do the job).

This would make much smoother the processing of "special"
material which depends on events which have occured earlier
in the troff run. For example, in 'pic' is is useful to
know the width of a string of text before you draw a box
round it. So you could write

.nr twid \w' This is text in a box 'i
.PS
box width \n[twid] "This is text in a box"
.PE

but of course \n[twid] can only be set by 'troff', and this
has not been done when 'pic' sees the ".PS/.PE" block.

> just an idea: the problem would go away if the `.so'
> request could be told (by a second argument to the request)
> to rerun all necessary preprocessors on the sourced file
> before inserting it (the preprocessors could be those
> specified in the groff call or explicitely specified to 
> the `.so' reguest).

Well, this particular problem might go away, but it is only
one instance of a class of similar problems (see above).
And you suggestion is of course on the same lines as my
"mad idea" above.

> would this be a good idea

It could be ... !

> (apart from the  someone_has_to_implement_it aspect)?

... but that looks like a bad idea :)

Best wishes,
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 094 0861
Date: 18-Aug-06                                       Time: 15:53:05
------------------------------ XFMail ------------------------------