groff
[Top][All Lists]
Advanced

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

Re: [Groff] The future redux


From: Clarke Echols
Subject: Re: [Groff] The future redux
Date: Thu, 27 Feb 2014 17:51:03 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1



On 02/27/2014 05:28 PM, Tethys wrote:
Deri James writes:


I firmly believe that groff doesn't necessarily need to change to stay
relevant (arguably, it hasn't been relevant to the majority for some time
anyway). Yes, separation of presentation from content is important. But
does it need to be done within groff? I'm not so sure. You risk turning
groff into something else entirely. At which point, why not just leave
groff as is, and write the something else as a separate program? Potentially
one that outputs groff input files if necessary, and HTML/whatever as an
alternative for those that want such things.


The big strength of Unix is its original design paradigm: An operating
system made of discrete software components, each of which does one
thing very well.

Consequently, shell scripts I wrote in 1989 on HP-UX will run unaltered
in 2014 on my Linux machine if I have nothing more than the same files
in the same directories.  No changes to 1989 vi, no changes to sed, or
any others.

Microsoft can't even get from one year to the next without breaking
everything.

Packaging features into combinations that can use existing components
may be workable, but sofware's not my forte.

My preference is let groff be groff and remain a useful tool that other
programs can use in a pipe or other means.

Clarke



reply via email to

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