From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 10 Jun 2004 13:58:49 +0300 From: Aharon Robbins Message-Id: <200406101058.i5AAwnoX018810@skeeve.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] troff and 4.4BSD man pages In-Reply-To: References: <05e301c44944$79faa650$9a7e7d50@SOMA> <20040607131901.GA84365@ix.netcom.com> Cc: Topicbox-Message-UUID: 9b35ba44-eacd-11e9-9e20-41e7f4b1d025 In article Doug Gwynn wrote: >Jon Snader wrote: > > What's unfortunate is that our bashing is often misinformed, both > > in spirit and in detail. The above comments are a case in point. > > Is there anyone here who really maintains that the two character > > name space in [nt]roff is not a disadvantage? Why should we > > complain that groff has removed this disadvantage? Why should we > > not remove it from [nt]roff? The answer given above is that the > > extension is incompatible, but that is incorrect. The groff > > rules for using registers are the same as for [nt]roff except ... > >Too bad you didn't bother to understand the comment to which >you replied. The incompatibility I mentioned was between >groff and SoftQuad's prior extension of the register names. >Now there are multiple formats for extended troff source >documents, something that could easily have been avoided. SoftQuad's troff is pretty much dead, and has been that way for quite a while. You can't find it on their web site and I wonder who is still using it? O'Reilly used it for some of their books, but they switched to using GNU Troff for their formatting a large number of years ago, keeping SQtroff only for reprints of the books done with it. (FWIW, even they have moved off troff to other technologies.) In terms of sheer numbers, SQtroff can't hold a candle to Groff, and I'd be curious to know how many people are still using SQtroff at all. As also mentioned, Groff is an *excellent* troff implementation. With the compatibility flag, I have successfully printed Unix documentation from 1980 with zero problems. (The System III doc for the MM macros, using the System III tmac.m file!) I have even had groff diagnose mistakes in my input files that Unix troff just silently accepted! > > What's unfortunate is that many of us here act as if no one else has > > anything to teach us. > >The GNU developers seem to provide support for that. I beg your pardon? I, at least, as a GNU developer, am well aware of what there is to learn from others. Other GNU developers are no more subjective about their work than many of the people here are. Which was the original poster's point, methinks. Two more cents out of pocket, Arnold