Re: [Groff] The future redux

2014-02-27 Thread Walter Alejandro Iglesias
On Wed, Feb 26, 2014 at 10:55:31PM -0500, James K. Lowden wrote: > On Wed, 26 Feb 2014 11:46:32 + > Ralph Corderoy wrote: > man pages don't really need expressive typography. >>> >>> Man pages are constrained by xterm. A better display system would >>> invite tables, graphs, equations, a

Re: [Groff] The future redux

2014-02-27 Thread Tadziu Hoffmann
> I submit to you that if our command-line environment weren't > still using 1980s technology to emulate 1970s hardware, we > would have more graphical and unified documentation. I think two factors are responsible for that: 1. In the sixties and seventies, computing was largely experimenta

Re: [Groff] The future redux

2014-02-27 Thread Charlie Kester
On Wed 26 Feb 2014 at 19:55:31 PST James K. Lowden wrote: Luckily, the terminal is also the solution. Or, rather, a different terminal would be. I call it VT-roff: http://www.schemamania.org/troff/vt-roff.pdf Interesting article. Thanks for sharing it. My first reaction was to won

Re: [Groff] The future redux

2014-02-27 Thread Eric S. Raymond
Charlie Kester : > Disagree with your assertion that ncurses-based apps are dead or dying. > For example, there are a lot of people using mutt for email and the > non-GUI version of vim for general text editing, and these (and many > other ncurses apps) are actively maintained. I concur with this

Re: [Groff] The future redux

2014-02-27 Thread Tadziu Hoffmann
> My first reaction was to wonder why not simply have a > commandline driving graphical output in another window. > But I see your point about having a history connecting > commands to the output. I'm just not sure how often I > would actually need that. Have you ever used Mathematica? The Math

Re: [Groff] The future redux

2014-02-27 Thread Walter Alejandro Iglesias
> 1. In the sixties and seventies, computing was largely > experimental. There were no penalties for trying > something different. It's the natural evolution of everything. In the beginning trying different approaches is sane and has sense. But to make a graphical version of what is al

Re: [Groff] The future redux

2014-02-27 Thread Tethys
Deri James writes: >I have, so far, kept silent on future direction for groff, since my >own use for groff is probably very rare, so my opinion should not >carry much weight. I use groff as a typesetting engine called from a >front end which produces a troff file which is then passed to groff to

Re: [Groff] The future redux

2014-02-27 Thread Clarke Echols
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

Re: [Groff] The future redux

2014-02-27 Thread Chad Roseburg
This is the primary use case for us as well [ typesetting backend ] though I do write other reports by hand using groff as well. For my needs the macros are easy to type, remember and produce pretty great looking reports. On Thu, Feb 27, 2014 at 4:28 PM, Tethys wrote: > > Deri James writes: >

[Groff] man pages (tangential to Future Redux)

2014-02-27 Thread Doug McIlroy
> Man pages are not tutorials or complete manuals As Federico said, they absolutely should be complete. Perhaps Gnu's most egregious contribution to Unix was to turn texinfo with its paleolithic interface into the "complete" documentation with man pages as stubs. But perhaps I should be glad that