Re: [Groff] Choosing a portability target

[Jon Snader]

On Wed, Jan 10, 2007 at 08:49:37PM -0700, Clarke Echols wrote:
> 

[...]

> I was somewhat hesitant to really accept the longer names
> allowed by groff because I usually prefer "backwards
> compatibility", but after taking advantage of it, I find it
> very nice in terms of keeping macros readable when I create or
> modify them.
> 

[...]

> 
> HOWEVER, if groff can be compiled and run on HP-UX,
> groff-oriented man pages will also need to be installed in the
> usual directories on HP-UX systems, and HP-UX users will expect
> to be able to run the man command on those pages.
> 
> THEREFORE, I think it would be wise to avoid using macro,
> string, or other entity names in gnu man page macros that
> violate the 2-character rule.  Same applies to me and ms
> macros.  If you want to use expanded-length names in a macro
> package, it should have a different name so the user doesn't
> expect it to run under nroff(1) on HP-UX/Solaris/AIX systems.
> 

I used to believe something similar to this myself, but I have
since reevaluated those beliefs.  There really isn't any reason
to be using (much less paying for) the traditional DWB these
days.  There are at least two much better solutions.  There is,
of course, groff, with which we are all familiar.  Additionally,
Gunnar has taken the traditional troff and turned it into a
really spectacular tool,  It does long names like groff, and can
also format a paragraph at a time, like TeX, as well as other
improved typesetting functions.  Both of these are free and
compile on HP-UX/Solaris/AIX; why would anyone want to still be
using AT&T troff?

Of course, people *are* still using it, but my guess is that
those installations are pretty much hidebound and won't be
updating their man pages, much less using the type of
browser-base man page viewing that Eric is advocating.  Those
HP-UX/Solaris/AIX installations not experiencing heat death need
merely install one of the (much improved) typesetters to take
advantage of the improved functionality that we've been
discussing.

In terms of the present discussion, *if* they have groff man
pages installed *then* they will almost certainly have groff
installed and the System Administrator can configure man to use
it.  I don't think we should go out of our way to break
compatibility with these systems, but I also don't think we
should take extraordinary measures to ensure that the new macros
will be compatible with those installations that probably won't
use them anyway.  In practical terms, this means that we should
use two-character macro names in the new general purpose macros
we define (like SY and OP) but not worry about changing long
macro names in existing man pages.  Let's face it, the systems
using the traditional troff won't be displaying those pages
anyway.

jcs