groff
[Top][All Lists]
Advanced

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

[Groff] Re: getopt() as gtroff macro ?


From: Steve Izma
Subject: [Groff] Re: getopt() as gtroff macro ?
Date: Wed, 22 Sep 2004 10:33:48 -0500
User-agent: Mutt/1.3.28i

> From: Keith MARSHALL <address@hidden>
> Date: Mon, 20 Sep 2004 11:09:59 +0100
> Subject: Re: [Groff] getopt() as gtroff macro ?
> 
> Heinz-J?rgen Oertel wrote:
> > More and more gtroff macros needs to handle arguments
> > in a generic way.  Is there something like getopt(3)
> > available, may be already implemented in some other
> > macro packages, ms, me, mm, or the more modern ones
> > like mom?
> 
> FWIW, here's the technique I've adopted in my PDF macro
> set, (which I plan to contribute, but it isn't quite stable
> enough yet, for public consumption).
> 
> The macro I have provided to place an active reference
> has the syntax:
> 
>   .pdfhref L [-D <dest-name>] [-P <prefix-text>] \
>      [-A <affix-text>] [-X] [--] <description>
> ...

I think this is important and, while I admire what Keith has
done, I wonder if there's any way to get a getopt built into
gtroff? I'm all in favour of facilities that move gtroff closer
to a programming language that has more of the basic facilities
we expect in structured programming. It's very close already and
adding getopt, for example, would help a whole lot, especially
for those of us who use groff extensively as a filter for
typesetting the output of many other processes, especially
database reports and XML. TeX/LaTeX was never designed for this,
so it seems to me that groff will continue to be crucial to many
programmers.

Related to this -- I recently heard that SoftQuad troff (the
development of which stopped about twelve or thirteen years ago
but the techniques of which, I'm told, formed the basis for a lot
of James Clark's implementation) had an undocumented facility for
local variables, i.e., a way of preventing things defined within
a macro of stomping on external things with the same name,
although it probably meant (I didn't get the details) that
prefixing a variable name with some special character within a
macro made it local; otherwise implementing local variables could
never be backwards compatible. I assume a related requirement
would be to get .return to actually return a value to the calling
macro.

Since I don't know anything about gtroff internals, I can imagine
poor Werner throwing up his hands and saying "Why not ask for pie
in the sky?!" So my apologies if these things are completely
unrealistic. I'm just suggesting them on the offchance that
someone with coding skills greater than mine is considering such
work and this is my way of encouraging them.

        Thanks
        -- Steve
-- 
Steve Izma
    Computing Systems Administrator       (519) 884-0710 ext. 6125
    Wilfrid Laurier University Press      FAX: (519) 725-1399
    Waterloo, Ont., Canada N2L 3C5        address@hidden




reply via email to

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