groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: M Bianchi
Subject: Re: <OK> Re: [Groff] soelim and file names defined in string registers
Date: Tue, 22 Aug 2006 10:23:46 -0400

On Tue, Aug 22, 2006 at 02:42:47PM +0100, Keith MARSHALL wrote:
> Mike Bianchi wrote:
> >>> (it just would be nice if the `.so' request _could_ interpolate the
> >>> string register value)
> >>
> >> Indeed, but I don't see how to do that properly.
> >
> > Maybe soelim(1) could recognize that the argument is not a file name
> > ( \ being a dead giveaway ) and simply leave the reference in place for
> > interpretation by groff?
> 
> This is exactly what happens, at present.

I don't see that behaviour documented in the man page.
 
> > As long at the referenced file does not require preprocessor
> > interpolation ...
> 
> ...in which case, `soelim' isn't really required, in the first place; it
> doesn't become necessary, until you have content in a `.so'd file, which
> *does* require interpretation by a preprocessor.
> 
> > And maybe have groff recognize a special form of .so :
> >
> >                .so filename [ preprocessor_command_line ]
> >
> >   .e.g.
> >                .ds filename FILENAME
> >                .so \*[filename] "tbl -  |  eqn -"
> > implies
> >                cat FILENAME  |  tbl -  | eqn -
> > or equivalently
> >                <FILENAME  tbl -  |   eqn -
> 
> May appear attractive, at first glance, but still inevitably suffers
> from the limitations Tadziu mentioned -- each `.so' so deferred is
> processed in isolation, and normally global declarations such as
> 
>         .EQ
>         delim ##
>         .EN
> 
> don't propagate as expected.

I have not been following the discussion closely, so I am shooting a bit from
the hip.  Sorry.

It seems to me that if a included file has eqn(1) equations that require
         delim ##
it is reasonable to include that declaration within the file.  Still there may
be other things that carry from equation to equation that would cause problems.


I suppose the real issue is the utter independence of the preprocessors from
groff.  If tables, equations, etc. are to be first-class citazens of groff they
need to share the entire groff environment.  Sounds like we are stuck with what
we have until we are willing to break a lot of things that currently "work".

-- 
 Mike Bianchi




reply via email to

[Prev in Thread] Current Thread [Next in Thread]