hi list,
as author of several man pages i can say something about the "other" side.
When you read the current manuals (i admit that is some time ago) they ask
the authors to keep the file simple. Using the .TH, .BR, .I macros
means that the authors need to learn a few basic format stuff and that's
> > You've forgotten to store something in register `a'.
>
> On reflection, I think that should probably be ".ad b". It's
> supposed to be restoring the normal adjustment mode for a man page.
I disagree. Perhaps someone likes to make the appearance of man pages
formatted with -man similar to th
> The groff project -- and I'm not sure what that means, other than
> "Werner Lemburg" --
Hmm, this is the same as Erik S. Raimont. :-)
> Target 2: man2html compatibility
This sounds reasonable. However, in case there are really stupid and
brainless issues in man2html, let's not uglify the gro
> In practical terms, this means that we should use two-character
> macro names in the new general purpose macros we define (like SY and
> OP) but not worry about changing long macro names in existing man
> pages.
That's exactly my point of view.
Werner
___
> HOWEVER, if groff can be compiled and run on HP-UX, groff-oriented
> man pages will also need to be installed in the usual directories on
> HP-UX systems, and HP-UX users will expect to be able to run the man
> command on those pages.
If groff finds another troff package already installed on th
> I am about three-quarters of the way through cleaning up the groff
> manual pages to be viewer-portable. The new versions will also be
> simpler, shorter, and easier to read than the old. I've done these
> so far: [...]
If you've reached a satisfying level, please mail them to me.
> Many gro
> That sequence of bracket characters starting with \bv is new to me
> -- I gather that has been introduced in CVS recently?
What sequence do you mean? The glyph \[bv] has been there since ever.
And no, I no longer add new glyphs to groff using ad-hoc glyph names.
The groff glyph list is frozen
> I understand what tty-char.tmac is doing now, and I am appalled.
>
> No inclusion of this file should *ever* occur visibly in a manual
> page.
Mhmm, yes, you are probably right.
> Either this should be invisibly included by andoc-tmac, or expansion
> of these glyphs should be done at the devic
> > > > I have not removed any instances of .URL or .MTO.
> > >
> > > .URL and .MTO are not two-character names.
> >
> > I'm still missing something. Are you saying that I should have
> > changed all of the existing instances of URL and MTO into
> > two-letter macros?
>
> Yes.
I don't mind to u
> Why does backslash render as a yen symbol when I do M-x man 7 man?
Because you are using the wrong locale, or the system is set up
incorrectly. There are ASCII variants (or rather, ISO 646 variants
like ISO 646-JP) which replace some ASCII characters. That's the very
reason why there exists
Werner LEMBERG <[EMAIL PROTECTED]>:
>
> > > You've forgotten to store something in register `a'.
> >
> > On reflection, I think that should probably be ".ad b". It's
> > supposed to be restoring the normal adjustment mode for a man page.
>
> I disagree. Perhaps someone likes to make the appeara
Werner LEMBERG <[EMAIL PROTECTED]>:
>
> > That sequence of bracket characters starting with \bv is new to me
> > -- I gather that has been introduced in CVS recently?
>
> What sequence do you mean? The glyph \[bv] has been there since ever.
> And no, I no longer add new glyphs to groff using ad-
Werner LEMBERG <[EMAIL PROTECTED]>:
> Please bear in mind that it is not the goal of man pages which come
> with the groff package to be readable by all Unix versions! I'm
> definitely *not* going to replace \[xx] with \(xx, for example.
Unfortunately, we might need this change anyway. I'm check
Werner LEMBERG wrote:
I just fixed up ditroff.man. This is going fairly smoothly so far.
Your past macro coders have had bad cases of "ooh! nifty feature!
must use!",
:-)
but despite that the code is pretty readable.
It's not really clear to me what you mean with `macro coders'.
W
Werner LEMBERG <[EMAIL PROTECTED]>:
> > I am about three-quarters of the way through cleaning up the groff
> > manual pages to be viewer-portable. The new versions will also be
> > simpler, shorter, and easier to read than the old. I've done these
> > so far: [...]
>
> If you've reached a satisf
Werner LEMBERG <[EMAIL PROTECTED]>:
> > In practical terms, this means that we should use two-character
> > macro names in the new general purpose macros we define (like SY and
> > OP) but not worry about changing long macro names in existing man
> > pages.
>
> That's exactly my point of view.
Th
walter harms <[EMAIL PROTECTED]>:
> Stuff like tbl,eqn,... is discouraged (somebody mentioned it before) to keep
> thinks simple.
Discouraging TBL is the wrong advice to give nowadays. It used to make sense,
back before the .\" t convention evolved and when most-third-party viewers
would just ign
Werner LEMBERG <[EMAIL PROTECTED]>:
>
> > HOWEVER, if groff can be compiled and run on HP-UX, groff-oriented
> > man pages will also need to be installed in the usual directories on
> > HP-UX systems, and HP-UX users will expect to be able to run the man
> > command on those pages.
>
> If groff f
Werner LEMBERG <[EMAIL PROTECTED]>:
> > Target 2: man2html compatibility
>
> This sounds reasonable. However, in case there are really stupid and
> brainless issues in man2html, let's not uglify the groff man macros
> just to cope with them. Instead, force the man2html maintainers to
> fix them!
Werner LEMBERG <[EMAIL PROTECTED]>:
> > Why does backslash render as a yen symbol when I do M-x man 7 man?
>
> Because you are using the wrong locale, or the system is set up
> incorrectly. There are ASCII variants (or rather, ISO 646 variants
> like ISO 646-JP) which replace some ASCII charact
Eric S. Raymond wrote:
> walter harms <[EMAIL PROTECTED]>:
>> Stuff like tbl,eqn,... is discouraged (somebody mentioned it before) to keep
>> thinks simple.
>
> Discouraging TBL is the wrong advice to give nowadays. It used to make sense,
> back before the .\" t convention evolved and when most
Werner LEMBERG <[EMAIL PROTECTED]>:
> Maybe I should just activate it there. Objections?
None from me.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
walter harms <[EMAIL PROTECTED]>:
> i am a big fan of tables (for a different reason) but we can not change that
> if the (man page) maintainers do not enforce it. someone should contact them
> and perhaps they have some nice additional ideas that should be incorporated.
There's no one set of main
Werner LEMBERG <[EMAIL PROTECTED]> wrote:
> > HOWEVER, if groff can be compiled and run on HP-UX, groff-oriented
> > man pages will also need to be installed in the usual directories on
> > HP-UX systems, and HP-UX users will expect to be able to run the man
> > command on those pages.
>
> If grof
Eric S. Raymond <[EMAIL PROTECTED]>:
> There's no one set of maintainers that can "enforce" such a convention.
> Most man pages belong to individual progress.
Individual *projects*. I'm clearly not awake yet...
--
http://www.catb.org/~esr/";>Eric S. Raymond
__
Eric S. Raymond wrote:
walter harms <[EMAIL PROTECTED]>:
>> It would be a nice step forward to add stuff like pic into man
pages aka
'a picture says more that 1000 words' (think of flow charts)
In fact, on systems running groff there's no problem with this.
The constraint has always been t
Clarke Echols <[EMAIL PROTECTED]>:
> In the case of the 1800 or so man pages I was responsible for at HP,
> I *never* encountered a need for anything like pic.
I hear you. I happen to like pic, but for man pages it is a frill
rather than a necessity.
> It would be nice to be able to have an ind
> I know \[bv] is old. I mean this sequence that it begins, which wasn't
> present when I first wrote doclifter:
>
>⎪ \[bv] braceex u23AA vertical exten‐
> sion
[...]
These glyphs have been t
[About .IX]
> It might not be a bad idea to bless this practice in the
> groff_man(7) documentation. Unlike some other extensions, it can't
> cause a compatibility problem, because .IX can be safely ignored.
Good idea.
Werner
___
Groff mailing
> > > On reflection, I think that should probably be ".ad b". It's
> > > supposed to be restoring the normal adjustment mode for a man
> > > page.
> >
> > I disagree. Perhaps someone likes to make the appearance of man
> > pages formatted with -man similar to the ones formatted with
> > -mdoc, th
> > Please bear in mind that it is not the goal of man pages which
> > come with the groff package to be readable by all Unix versions!
> > I'm definitely *not* going to replace \[xx] with \(xx, for
> > example.
>
> Unfortunately, we might need this change anyway. I'm checking
> now...the KDE bro
> > Perhaps something like this:
> >
> > .if \n(.g \{\
> > . do mso www.tmac
> > . do als UR URL
> > . do als MT MTO
> > .\}
> > .el \{\
> > . de UR
> > . ...
> > . de MT
> > . ...
> > .\}
> >
> > together with an update of www.tmac which says that man pages
> > shou
> > > HOWEVER, if groff can be compiled and run on HP-UX,
> > > groff-oriented man pages will also need to be installed in the
> > > usual directories on HP-UX systems, and HP-UX users will expect
> > > to be able to run the man command on those pages.
> >
> > If groff finds another troff package
> especially since b) could have the effect that many HP-UX manual
> pages will not render correctly anymore because the groff -man
> macros lack the HP-UX specific .CI, .IC, etc. macros which Clarke
> has mentioned.
See my other mail how groff handles this gracefully.
> I did not try this myse
Werner LEMBERG <[EMAIL PROTECTED]>:
> [About .IX]
>
> > It might not be a bad idea to bless this practice in the
> > groff_man(7) documentation. Unlike some other extensions, it can't
> > cause a compatibility problem, because .IX can be safely ignored.
>
> Good idea.
I'll put it on my to-do li
Werner LEMBERG <[EMAIL PROTECTED]>:
> A man page by default has to be defined in `traditional mode' (.cp 1).
> If groff extensions are used it should call
>
> .do nr _C \n[.C]
> .cp 0
>
> ... man page ...
>
> .cp \n[.C]
>
> [Another thing to mention in the forthcoming man writer's guide
Werner LEMBERG <[EMAIL PROTECTED]>:
> > Then I don't know what the right thing is here. I agree with your
> > design intention, but I can't see how to implement it robustly.
>
> Well, doclifter ignores it anyway, doesn't it?
Yes, but doclifter isn't the problem here, either.
> > Even querying
Werner LEMBERG <[EMAIL PROTECTED]>:
> > Unfortunately, we might need this change anyway. I'm checking
> > now...the KDE browser supports \[], but manServer doesn't. If it's
> > OK with you to break compatibility with manServer, then this is
> > fine. Since it can't handle .if, we probably would
Werner LEMBERG <[EMAIL PROTECTED]>:
> This is even better because we can avoid conflicts with the .URL
> macro. So let's add .UR and .UE, ignoring the .MTO macro -- the
> latter can be realized as
>
> .UR mailto:[EMAIL PROTECTED]
> Foo Bar
> .UE
As a design direction, I'm good with this. B
> > .SY
> > .SY
> > .YS
> >
> > it's just necessary to test a flag, say, \n(sy, which is set by
> > the first .SY call. If it's still set in the next call to .SY,
> > don't call the .ad request.
>
> OK. Can I rely on you to add that?
Yes. In case I forget please remind me :-)
Werne
> > A man page by default has to be defined in `traditional mode'
> > (.cp 1). If groff extensions are used it should call
> >
> > .do nr _C \n[.C]
> > .cp 0
> >
> > ... man page ...
> >
> > .cp \n[.C]
> >
> > [Another thing to mention in the forthcoming man writer's guide.]
>
> I've been
Werner LEMBERG <[EMAIL PROTECTED]>:
> ??? Things like \[rs] will definitely fail in classical troff
> implementations. So what do you mean with `traditional mode'?
I should have said I'm testing to be sure that they work in the
default mode, rather than needing compatibility mode to be forced of
42 matches
Mail list logo
