[Top][All Lists]

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

Re: [Groff] Strange error messages from Groff 1.22.3

From: Steffen Nurpmeso
Subject: Re: [Groff] Strange error messages from Groff 1.22.3
Date: Tue, 11 Nov 2014 13:50:48 +0100
User-agent: s-nail v14.7.8-70-g9310369

Doug McIlroy <address@hidden> wrote:
 |* For a ludicrous example, when I type my own name,
 | M. Douglas McIlroy
 |at the beginning of a line--as for a signature or author line--
 |Open Office thinks that I've begun a paragraph numbered with
 |a Roman numeral, and proceeds to tack "MI." onto the beginning 
 |of the next line!
 |Groff has blessidly little AI. Let's keep it so.

This example is terrible -- i hope there are no dynamic and moving
advertisings at the time of this writing.  I only know similar
experiences from certain web experiences; a few years ago i called
it Flashnet, but what did i know... it's getting worse!

And whereas i do agree on your AI statement for groff,
i personally really would like to see more self-responsiveness of
roff documents.  E.g., just like many man(1) commands support
parsing of a specially marked first line (as in

  '\" egprtv
...[FreeBSD iirc:]
                while getopts 'egprtv' preproc_arg; do
                        case "${preproc_arg}" in
                        e)      pipeline="$pipeline | $EQN" ;;
                        g)      GRAP  ;; # Ignore for compatibility.
                        p)      pipeline="$pipeline | $PIC" ;;
                        r)      pipeline="$pipeline | $REFER" ;;
                        t)      pipeline="$pipeline | $TBL" ;;
                        v)      pipeline="$pipeline | $VGRIND" ;;
                        *)      usage ;;

it would make sense to extend this with an encoding, make it all
more user-friendly, as in, e.g. (staying compatible)

  '\" t -- preprocess: tbl(1)

and get rid of, let me say, accidents like grog(1).
Noone knows better than the author of a document what the document
needs, so the document should be able to specify what it needs.

And likewise, in my opinion, not being able to create a table of
content or an index from within the macros feels uncomfortable and
incomplete.  I hope that for my upcoming S-roff fork i will be
able to implement a controllable multipass mode that macros (or
top-level documents) can enable at will.  Like that, and possibly
with some more string manipulation and other support functions,
macro writers will be able to create TOCs and indices all from
within macro space, and a single troff (pipeline) invocation will
create the final document; i.e., different to TeX where there is
no pipeline but it is still annoying that you need to run it two
or three times until your macros got it all right, a pipeline
based approach has an irresistable urge to create a result at
the end.  I do think the missing multipass mode of troff is
a design mistake, but on the other hand troff is only one program
of a huge environment and since shell scripts can easily hide the
problem as described maybe noone ever had the desire to spend the
(necessary money and) time to go that route.  I hope i can afford
that over the years.


reply via email to

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