Sorry, gang. I sent this to Eric instead of to the list. ----- Forwarded message from Peter Schaffter <pe...@schaffter.ca> -----
Date: Wed, 5 Mar 2014 14:29:25 -0500 To: "Eric S. Raymond" <e...@thyrsus.com> From: Peter Schaffter <pe...@schaffter.ca> Subject: Re: [Groff] Back to the future On Tue, Mar 04, 2014, Eric S. Raymond wrote: > Peter Schaffter <pe...@schaffter.ca>: > > Whether, or how, well-formed files and macrosets > > should/could be xml/stylesheet-parsable in a semantic world has no > > bearing on groff's future. It's a front-end debate when back-end > > development is what's needed. > > But this I disagree with on multiple counts. > > Firstly, front end and back end issues are *not* orthogonal, because > nobody is ever going to design groff macros in a way that is totally > decoupled from the capabilities of groff's back end. (And even > intending to do that would be silly.) > > Secondly, I think you can maintain this position only by taking an > ahistorically narrow view of what 'groff' now is. Like it or not, we > remain responsible for supporting some important non-typesetting > use cases - notably, man pages browsed through terminal emulators. We absolutely do not disagree on the above items. Occam's Hatchet: I chopped *everything* away so we could look at the cleanest bare bones. Perhaps I didn't phrase my position clearly. God knows, that's easy enough to do in email, even for a practised writer. I sensed that discussions about manpages/xml/etc were distracting *at this stage, and at this stage only*. You pointed out that groff was getting close to life-support, so I applied basic First Aid triage: breathing, bleeding, breaks, burns. Breathing is the backend (formatting engine, requests). Bleeding is manpages. Breaks is groff-in-an-xml-world. Burns is real-number arithmetic, order of operations, etc. I hope my analogy isn't so stretched it fails to make its point. Basically, I was talking about trimming away beclouding *debate* (again, only at this stage), not proposing a future in which groff is impoverished by too narrow a focus. For the record, I feel that groff's evolution, if it is to happen, should be practically invisible in terms of user deployment. Whatever worked should continue to work, just better. I propose an improved groff, not a new one. It's why I'm increasingly dead-set against forking. There is simply no need. Damn, I hate it when I go on long, but something difficult to quantify is also part of the groff picture. *roff is a system that continues to perform in a backwardly-compatible manner practically to its inception forty years ago. If groff had a soul, that's something it would be proud of. It's resisted fashion without becoming an obsolete. It's a testament to, a proof of concept of, the Unix philosophy and the hacker ethic in general. Wherever groff goes from here, I would never want to lose that. > We can't simply abandon that job; it follows that we need to think about > how to do it better, and - if you really want groff to narrow its scope > to be a typesetting back end only - we need to think about how to hand > off that job and what to hand it to. > > Fortunately for your vision, that is *precisely* what *I* have been doing... I follow where you're going with your grand project, and support it entirely. Documentation for *nix is a subject of great concern to me. A little-known fact about the mom macros: from the start, the project has been a test-bed for my theories about documentation: content and style, presentation, usefulness, ease of use. From the start, it's been entirely html (converted later to xhtml). I've even resisted the urge to create a pdf version, which, it strikes me, would be nothing more than showing off. If that doesn't tell you how closely we're aligned, nothing will. :) > > The manpages debate is largely about groff usage, not > > groff development. > > No. In the terms of argument you yourself have chosen, it's a debate > about the design philosophy of front-end macros. You are free to try > to pretend that this is not an aspect of groff development if you like, > but I am quite certain the rest of the world will not accommodate you in > this. Again, we're on the same page. As you point out, front and back end issues are not orthogonal. However, addressing front end issues requires a slightly different approach from back end ones, hence my wish to keep them separate--but only during the hammering out process. > > One shouldn't have to be a geek to benefit from the advantages, > > which leads me to think that, ancillary to backend improvement, > > there's a pressing need for groff advocacy. Put another way, folks > > need to know that using groff to format a novel isn't novel. It's > > pretty routine, and you shouldn't have to be a hacker to do it. > > Me, I think this is a doomed enterprise. For this use case the rest of > the world has moved on to DocBook, wiki-style markups, markdown, and > asciidoc (that is, if they're not using a WP to begin with). I can't > see any reason at all it should look back. > > If you want to preserve a role for groff, you need to start by being > realistic about the range of use cases it's fit for in 2014 and going > forwards. Formatting of the general run of novels by casual users is > not among then; that's *gone*, already lost to tools that play better > with ePub. This is a toughie, and it's where my beliefs, principles, standards, and concerns for the future come into play--quite possibly in a detrimental fashion, but maybe, just maybe, beneficially. As early a 2002, UNESCO issued a warning about the preservation of digital data. At the time, the paper focussed on preserving the equipment necessary to read binary data, but it seemed evident to me that preserving content was the more important goal, hence the immense importance of formatting systems that take plain text files as input. Groff is one such system, and while it may be a finger-in- the-dike, it's worth remembering that that finger, in Mary Dodge's story, prevents Holland from being inundated. I say this because you are quite right: the use case for groff by writers of non-technical works--who, for the purposes of simplicity, I refer to as "prose writers"--is practically nil. A situation unlikely to change if groff remains, in the general imagination, a geeks-only tool. The enterprise may be doomed, but I'm not one to abandon ship just because the rats are fleeing. > > Why do I care? Well, with the greatest of respect to Eric, I > > feel that "the page", as it has been recognized for centuries, > > is far, far from being irrelevant to the future of material > > intended to be read at the screen. > > I think we'll just have to disagree on this. You sound to me like > a Babylonian scribe arguing that reading won't be *right* without > the feel of the clay tablet in the reader's hands. No, nothing like that at all. My position, and the arguments I bring to bear on it, are more nuanced. But I understand how you could mistake me for an "I just like the feel of a good book in my hands" type of guy. I'm sure I come across that way. Truth is, I've been promoting "good type on the screen" for years. > 4. Identify 'semantic' macro packages, including man markup and possibly mom. > Work towards systematically isolating those macro sets from groff-specific > back end details, with the general direction of making them more semantic > and enabling simpler non-groff rendering engines for terminal and web use. Yes, yes, and yes. > 5. Improve the semantic expressiveness of man markup. Hallelujah! > I'm willing to work on these things, not just talk about them. To > be more concrete, I'm willing to own the cluster of design and > implementation problems around man macros. Speaking for myself, I welcome this. It puts you in charge of an important component of your larger documentation vision. What do others think? (Actually, it's beginning to look as if this is a _fait accompli_.) Now, on to the final issue... > All hail the new project leader! :-) My recent contributions to the list haven't been a bid to take on that role, however they might read. I am not sufficiently adept at the coding and administrative skills required. If I may use an analogy, I'd be like a conductor who knows that an orchestral passage requires perfectly synchronized pizzicato but hasn't the violin chops needed to coax it from the players. The project needs a conductor, it's true (reference to Werner's meat-world profession unintended), but it needs a concert master, too, a person or corpus capable of implementing the details--ie the coding--of the larger vision. Without that, it's all talk and no walk. ----- End forwarded message ----- -- Peter Schaffter http://www.schaffter.ca
