groff inquiry

[quinlan@spectrum.cs.bucknell.edu (Daniel Quinlan)]

I have a simple question or two and I would like to hear if anyone has
any interesting thoughts.  If you don't really care, if you only have
blatantly obvious things to add, or if you don't use groff often, then
please spare the list.

1. Should the Debian groff package include backwards-compatibility
   symlinks for the binaries?  Symlinks would probably be only:

        eqn    -> geqn
        neqn   -> gneqn
        nroff  -> gnroff
        pic    -> gpic
        refer  -> grefer
        soelim -> gsoelim
        tbl    -> gtbl
        troff  -> gtroff

I think including these links is a *bad* idea for a number of reasons:

 .  Programs are not equivalent and, in some cases, behave radically
    different, from non-GNU troff packages.

 .  Many commands are left out woefully left out in the list of
    symlinks because groff "offers that much more".  (Linking only
    about half and ignoring the rest!)

 .  Not a significant cost in loss of compatibility.

 .  `groff' front-end program obviates the need for using most of
    these programs.  It is highly recommended that it be used, as
    well.

 .  All GNU software which uses roff checks for different versions
    (gnroff vs. nroff).

 .  Forcing the "g", makes people realize that it is a very different
    program from AT&T or BSD troff (C/A/T or ditroff).

 .  manual pages list everything as 'gtroff'.  The 'g' is more
    expected these days, etc.

 .  Options and processing are different enough that backward
    compatibility can't be assumed anyway.

 .  Some programs AREN'T compatible AT ALL with traditional troffs
    (C/A/T troff and ditroff), i.e., gpic and geqn.

 .  Manual pages all refer to g'ed versions.

 .  The maintainer (me) is biased towards GNU project programs and
    objects to naming them after AT&T commands just so people have
    leave out a letter on the command line.  (In five years, will 1/3
    of all commands start with a g? // Gosh, I hope not.)

 .  I could go on, too.

2. On the other hand, I am thinking about renaming (it is a Makefile
option, actually) the tmac files `tmac.gm', `tmac.gmse', and `tmac.gs'
to `tmac.m', `tmac.mse', and `tmac.s', respectively.  I think this is
a good idea because:

  . Everyone does it.  (Peer pressure!)

  . Easier to leave out the dumb "g".  (Odd that I don't list this as
    a "con" above, isn't it?)

  . Manual pages refer to the non-g'ed version.  (A real reason)

  . Manual pages are named groff_mm, groff_mmse, and groff_ms and not
    the other way around.  (A real reason)

  . People usually refer to the "mm" macros and not the "mgm" macros,
    etc.  (Isn't that special.)

I think that makes decent sense and unless anyone comes up with
something really convincing, that is how I'll probably do it.  I'm
considering linking the tmac files, but I don't think it is really
necessary, especially if I take out the "g".

Dan

--
Daniel Quinlan  <quinlan@spectrum.cs.bucknell.edu>