> Yes, normally I would be a stickler for backwards-compatibility to
> legacy Unixes. However, I feel that in the particular case of
> .EX/.EE and .DS/.DE there are several factors which, taken together,
> would make the slight degree of breakage involved an acceptable
> trade-off. [...]
To sum
> To summarize:
>
> . .EX/.EE and .DS/.DE should be added to the man macros.
>
> . .SY and .OP together with .TQ (as the `standard' extension to .TP)
> should be used within man pages, but its definitions should be
> copied to the limbo of each man page since we can't assume that
>
Werner LEMBERG <[EMAIL PROTECTED]>:
> To summarize:
>
> . .EX/.EE and .DS/.DE should be added to the man macros.
>
> . .SY and .OP together with .TQ (as the `standard' extension to .TP)
> should be used within man pages, but its definitions should be
> copied to the limbo of each man
Meg McRoberts <[EMAIL PROTECTED]>:
> Personally, what I really miss in the -man macros are the list macros from
> mm -- .VL, BL, .DL, et cetera.
I sympathsize, but that is an extension that would create more severe
compatibility problems. Given that, as you say,
> .
Meg McRoberts wrote:
What else?
Personally, what I really miss in the -man macros are the list macros from
mm -- .VL, BL, .DL, et cetera. .IP and .TP do work but are a bit awkward.
I've not been able to get the old kludge for bullet lists to work:
.IP "\(bu" 4
I don't understand the need
Clarke Echols <[EMAIL PROTECTED]>:
> .TP 3 \" set bullet offset
> \(bu \" or other character such as dash or square
I'm pretty sure doclifter will turn this into a DocBook bulleted list,
but I don't have any examples handy to test it on.
> Until this discussion, I had never see .EX/.EE and .DS
Hi Mike,
Mike Bianci wrote
> It also fails because it _insists_ on interactive navigation and there
> is no way (that I am aware of) to print out a definitive reference.
> Some of my mos t valued documents are info documents turned into a
> single, flat text file. E.g. make . I can drop into
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> 3. These macros are already present in at least some legacy Unixes.
> Notably, .EX/.EE is in Ultrix/OSF-1.
Yes, and I see it is actually used in many Tru64 manual
pages; since I want to be able to display such system pages
with Heirloom nroff, I shou
Gunnar Ritter <[EMAIL PROTECTED]>:
> > I'm not sure where .DS/.DE
> > came from, but considering the relatively large number of uses without
> > local definition I'm sure it must be historical somewhere.
>
> Can you say in which pages you discovered them? I find much
> fewer examples for .DS, with
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> > An examination of the CSRG archives shows that .Ds had been
> > defined in -mdoc as a "filled block display" in 4.3BSD-Reno,
> > but was deleted with 4.4BSD.
> >
> > Which DocBook tag should correspond to .DS?
>
> A *filled* block display?
Not rea
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> I have since written a little tool called 'mangrep' that recurses
> zgrep -l over the manual tree.
Heirloom Toolchest grep -rz :-)
> It shows me that in my corpus, DS is in
> these 21 files:
Okay, so this effectively means that two people assume .D
Gunnar Ritter <[EMAIL PROTECTED]>:
> > I have been translating it as an
> > unfilled block, with a tag -- that's what the examples
> > in my corpus seem to want, and the meaning it has in mm. It differs
> > from .EX/.EE only in that it doesn't force the font to CW.
>
> Then I do not understand w
Gunnar Ritter <[EMAIL PROTECTED]>:
> > It shows me that in my corpus, DS is in
> > these 21 files:
>
> Okay, so this effectively means that two people assume .DS
> exists, a Mutt and a FreeRADIUS documentation author. So I
> would not assume that it had been part of a variant of -man
> before.
Yo
Personally, I would prefer having .nf/.in/.fi used in man pages
over .DS/.DE -- the display macros hold the contents on a single
page and when writing man pages that might be rendered in plain text,
PDF/PS, or HTML, I'm not crazy about this model.
I am only a writer who has written a lot of docs u
The point here is on "my" in the sentence above.
What Mr. Ritter is saying all this time is that the number of cases
simply does not warrant the _unportable_ change to a well established
legacy format.
If doclifter handles all these cases as well as you already described
there is no need for an ex
On Sat, Dec 23, 2006 at 06:01:29PM -0500, Eric S. Raymond wrote:
> I use Emacs to edit DocBook markup directly.
That's not different from what I've been doing.
I wouldn't say that is a comfortable way of writing.
> For someone as bothered by tag verbosity as you are I would recommend
> using asci
On Wed, Dec 27, 2006 at 06:52:13AM -0500, Eric S. Raymond wrote:
> I don't think your citation of -mdoc is really on point. IMO, the
> reason it hasn't gained acceptance is that, while -mdoc markup is
> cleverly designed, it is also quite complex -- more heavyweight than
> most man-page writers wa
Zvezdan Petkovic <[EMAIL PROTECTED]>:
> If doclifter handles all these cases as well as you already described
> there is no need for an exception to man format.
It's going to be Werner's decision, ultimately.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Meg McRoberts <[EMAIL PROTECTED]>:
> I do like mm's .ne functionality -- this allows the writer to specify
> that the next lines need to stay together on a page -- it might force
> a page break if there isn't enough space left on the page, but it won't
> force a page break if there is room. But .
Zvezdan Petkovic <[EMAIL PROTECTED]>:
> > For someone as bothered by tag verbosity as you are I would recommend
> > using asciidoc, which can generate DocBook.
>
> I wonder why asciidoc?
Because it's the simplest way to compose DocBook-structured stuff I've
seen yet.
> Is it really any different
Zvezdan Petkovic <[EMAIL PROTECTED]>:
> If -mdoc was refused for the above reason, how accepted DocBook will be?
I'm not sure how much that matters. Nothing stops you from composing
in asciidoc or whatever; the whole conversion from composition format
to DocBook could take place out of your sight
Eric, I really like your long-term vision, but have some questions
to extend it a bit.
If all this were implemented, would you envision that people writing
new man pages would write them using -man or would they use docbook?
My concern right now is with man pages for third-party software.
I work
I spent many years writing man pages for kernel/driver interfaces
and the code examples there were often pretty long... It would be
good if the section 2 and section 3 pages had more code examples on
them -- I don't know if that will ever happen (maintenance and commenting
can become a pretty majo
Meg McRoberts <[EMAIL PROTECTED]>:
> If all this were implemented, would you envision that people writing
> new man pages would write them using -man or would they use docbook?
That would depend on your tradeoff between complexity and control.
Writing in man markup is the simpler way to go, but do
On Thu, Dec 28, 2006 at 11:11:34PM -0500, Eric S. Raymond wrote:
> > There is a deeper philosophical question here.
> > Who needs to tag a document for all the sorts of semantic or any other
> > meaning? Is it the author or somebody else?
>
> Who tags the man pages you write? Who should tag them
On Thu, Dec 28, 2006 at 08:51:37PM -0800, Meg McRoberts wrote:
> I'm not sure of the solution but it seems that, if they could write in
> docbook, this opens the option of using an XML WYSIWYG editor if
> necessary.
Which does not make the writing any faster.
Picking one of 100+ tags from the menu
> Personally, I would prefer having .nf/.in/.fi used in man pages
> over .DS/.DE -- the display macros hold the contents on a single
> page and when writing man pages that might be rendered in plain text,
> PDF/PS, or HTML, I'm not crazy about this model.
I like .DS/.DE very much, but it isn't us
27 matches
Mail list logo
