On 03/01/2007, at 9:18 AM, Clarke Echols wrote:
It is important to minimize clutter at the start of the page.
and later on :-)
the old AT&T page which combined them with a NAME line:
cp, mv, ln \- copy, link, or move files
Yeah, we had the same thing on our then top-of-the-world SGI syst
Here are some examples of what I did back in 1992 in the HP-UX
Reference manual. This is a good example of my thinking in what
makes a "useful" manpage:
http://docs.hp.com/en/B2355-90128/cp.1.html
I reviewed my copy of the entire manual (3000 pages, 1450 files)
and did not find any case wher
> On Mon, Jan 01, 2007 at 11:32:11AM -0500, Eric S. Raymond wrote:
> > Gunnar Ritter <[EMAIL PROTECTED]>:
> > > Eric S. Raymond wrote:
> > > ... and "don't write multiple description lines".
> > Multiple description lines?
> I'm talking about name sections like this:
>
> NAME
>bzip2, bunzi
M Bianchi <[EMAIL PROTECTED]> wrote:
> This would seem be argue for structural macros. E.g.
>
> .SH NAME
> .NamePurpose "bzip2, bunzip2" "a block-sorting file compressor, v1.0.3"
> .NamePurpose "bzcat" "decompresses files to stdout"
> .NamePurpose "bzip2recover""recovers da
M Bianchi <[EMAIL PROTECTED]>:
> But that form is _so_ much easier to read and understand, especially for the
> novice! That, to my mind, is the overriding goal of the exercise.
I agree. Unfortunately, I can't fix this. If the DocBook DTD were to loosen
so this were allowed, I would support it
Gunnar Ritter <[EMAIL PROTECTED]>:
> > I've described the two extensions I think would be merited. The sort
> > of good-practice guidelines I nean are things like "don't use troff
> > requests outside the safe set" and "don't put running-text notes in a
> > synopsis section" and "don't write multi
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> I've described the two extensions I think would be merited. The sort
> of good-practice guidelines I nean are things like "don't use troff
> requests outside the safe set" and "don't put running-text notes in a
> synopsis section" and "don't write mu
Larry Kollar <[EMAIL PROTECTED]> wrote:
> Gunnar Ritter wrote:
>
> >> D.E. Evans asked about an improved grohtml, or even a replacement.
> >> Perhaps grohtml can be improved.
> >
> > grohtml is broken by concept. It is thus impossible that
> > it will ever reach a satisfying state.
>
> This is a l
Larry Kollar <[EMAIL PROTECTED]>:
> But even if you aren't interested in generating (or converting to)
> HTML, whether markup is structured or presentational basically
> depends on what you call it. :-) For example, emphasis and
> citations might both be rendered as italic, but that doesn't mean
>
Gunnar Ritter wrote:
D.E. Evans asked about an improved grohtml, or even a replacement.
Perhaps grohtml can be improved.
grohtml is broken by concept. It is thus impossible that
it will ever reach a satisfying state.
This is a little off the subject, but I disagree. I'm already using
grohtm
On Dec 30, 2006, at 5:28 PM, Gunnar Ritter wrote:
mhobgood <[EMAIL PROTECTED]> wrote:
It's the 21st century, all the documentation on my system ought to
present as a hypertexted local Web through my browser.
Subject two. That is your personal preference. Myself, I'm quite
happy to use ot
mhobgood <[EMAIL PROTECTED]> wrote:
> > It's the 21st century, all the documentation on my system ought to
> > present as a hypertexted local Web through my browser.
>
> Subject two. That is your personal preference. Myself, I'm quite
> happy to use other forms for documentation; forms that
Michael D. Hobgood wrote on 12-30-2006:
>Subject two. That [hypertext] is your personal preference. Myself, I'm
quite
>happy to use other forms for documentation; forms that do not invoke
>my browser at all.
You have my best wishes to continue in good health such that you can
continue to
13 matches
Mail list logo
