Hi Colin,
Colin Watson wrote on Thu, May 04, 2017 at 07:07:28PM +0100:
> The main practical reason I've stuck with man(7) in some cases
> (such as in man-db)
Actually, for man-db, the choice of man(7) is somewhat understandable,
since man-db is most relevant in situations where mandoc(1) is not
On Mon, Apr 24, 2017 at 06:29:57PM +0200, Ingo Schwarze wrote:
> There is little you can do to make writing legacy man(7) code
> easier for the novice. The problem is that it always requires
> mixing two different language levels: man(7) macros and low-level
> roff requests and escapes. And that
At 2017-04-30T19:34:20-0400, James K. Lowden wrote:
> On Fri, 28 Apr 2017 01:15:05 -0400
> "G. Branden Robinson" wrote:
> > C adopted designated initializers, a sop to those who can't recall
> > what order a struct's fields come in.
>
> I guess you're implying that designated initializers, while
On Fri, 28 Apr 2017 01:15:05 -0400
"G. Branden Robinson" wrote:
> the benefit to the user is relatively few keystrokes above those
> > needed for the text.
>
> Did you write your DocBook-based user guide in ed?
>
> Nothing has come close to saving me more keystrokes than at the
> shell prompt
>
> *By mixing low-level roff(7) syntax into your mdoc(7) document, like
> defining*
*your own macros, you gratuitiously endanger portability.*
...
*You are being selfish. If you forcefully redefine standard macros, the
> result*
*will look unnatural to *everyone else**
Some documents I write
Hi,
Ingo wrote:
> Manuals tend to have so much font jumping anyway
> that they are often not very visually pleasing and look noisy.
That's true. And my crude understanding of typography is that ππ‘ππππ is
normally used for emphasis, with ππ¨π₯π being kept in reserve for that odd
time when t
Hi John,
John Gardner wrote on Sun, Apr 30, 2017 at 10:50:23PM +1000:
> .de XR
> . Xr \\fB\\$1\\fP \\$2
> ..
That's a bad idea for three reasons.
1. It already stands out by the (N), additional font change is not
required. Manuals tend to have so much font jumping anyway
that they are
Chained commands are easier to follow with syntax highlighting:
[image: Inline images 1]
But I'm still in agreement with Ralph here, at least with regards to
complex formatting. Lines like `.It Ar radius` are fine, but the Ns and No
commands... ugh. Even when formatting with mdoc, I find it benef
Hi Ingo,
> > > .Fl S Ar var Ns Op Pf = Ar value
> >
> > This has reminded me of one reason I didn't get on with mdoc. Only
> > the `Fl' is obviously mdoc's, due to the `.' invocation. The rest
> > are a mix of command and data, but without any sigil one's left
> > guessing unless the command set
Hi Ralph,
Ralph Corderoy wrote on Sat, Apr 29, 2017 at 03:47:53PM +0100:
> Ingo Schwarze wrote:
>> .Fl S Ar var Ns Op Pf = Ar value
> This has reminded me of one reason I didn't get on with mdoc.
> Only the `Fl' is obviously mdoc's, due to the `.' invocation.
> The rest are a mix of command and
Hi Branden,
> > The troff system was designed to be typed at a keyboard. The
> > dot-on-the-left rule might be ugly, and the requests/macros terse,
> > but the benefit to the user is relatively few keystrokes above those
> > needed for the text.
...
> Nothing has come close to saving me more keys
Hi Ingo,
> things are actually much simpler even for describing such unusually
> complicated syntax:
>
> .Oo : Ns Fl c Ar cc-addr : Oc
> .Eo [: Fl c Ar cc-addr Ec :]
>
> .Fl S Ar var Ns Op = Ns Ar value
> .Fl S Ar var Ns Op Pf = Ar value
This has reminded me of one reason I didn't get on with mdo
i wrote:
|Ingo Schwarze wrote:
||Steffen Nurpmeso wrote on Tue, Apr 25, 2017 at 08:19:21PM +0200:
...
||P.S.
||Only bacause i'm replying anyway and it's just five lines:
|
|Sure.
|
||> .Op : Ns Fl c Ar cc-addr Ns \&:
||> .Fl S Ar var Ns Op Ns = Ns Ar value Ns
||
||That's full of ca
i wrote:
|Ingo Schwarze wrote:
||Steffen Nurpmeso wrote on Tue, Apr 25, 2017 at 08:19:21PM +0200:
...
|As above. That is all for today, i spent three hopeless hours in
|the pic lex code, even shallow cloned 67 MB of gnulib for a few KB
|of datatable that doesn't get used the right way, and
Deri James wrote:
|On Thu 27 Apr 2017 23:48:29 Steffen Nurpmeso wrote:
|> Terrible, see the spacing errors surrounding the command list
|> before the "Substitution" heading! Not your fault of course, but
|> gr...
|>
|> --steffen
|
|Well, turns out it WAS my fault! Bug in gropdf, will
This touches on something I experienced recently. I wanted to write a
JavaScript module that would help developers generate manual-pages for
their projects (because there's a searing lack of manpages in the Node
community...).
I ended up ditching that idea when I realised developers would still be
At 2017-04-27T23:38:23-0400, James K. Lowden wrote:
> On Wed, 26 Apr 2017 09:46:43 -0400
> "G. Branden Robinson" wrote:
>
> > 1. The slavish devotion to two-letter names for things, which like the
> >man macro package and the oldest parts of *roff itself, make it
> >self-anti-documenting.
On Thu, 27 Apr 2017, James K. Lowden wrote:
The troff system was designed to be typed at a keyboard. The
dot-on-the-left rule might be ugly, and the requests/macros terse, but
the benefit to the user is relatively few keystrokes above those needed
for the text.
A corollary of this is that i
On Wed, 26 Apr 2017 09:46:43 -0400
"G. Branden Robinson" wrote:
> 1. The slavish devotion to two-letter names for things, which like the
>man macro package and the oldest parts of *roff itself, make it
>self-anti-documenting.
Having written one user guide in DocBook, I have to disagree
On Thu 27 Apr 2017 23:48:29 Steffen Nurpmeso wrote:
> Terrible, see the spacing errors surrounding the command list
> before the "Substitution" heading! Not your fault of course, but
> gr...
>
> --steffen
Well, turns out it WAS my fault! Bug in gropdf, will commit after more
testing. Thanks
Deri James wrote:
|On Thu 27 Apr 2017 20:12:09 Ingo Schwarze wrote:
|> Does that still apply to
|>
|> view-source:http://man.openbsd.org/ksh
|
|compared with a PDF version:-
|
|http://chuzzlewit.co.uk/WebManPDF.pl/man:/1/ksh
Terrible, see the spacing errors surrounding the command list
Ingo Schwarze wrote:
|Steffen Nurpmeso wrote on Tue, Apr 25, 2017 at 08:19:21PM +0200:
|> the HTML output of mandoc used repeated per-paragraph style
|> directives and a CSS file, which caused enormous bloat, last
|> time i tried.
|
|Does that still apply to
|
| view-source:http://man.ope
On Thu 27 Apr 2017 20:12:09 Ingo Schwarze wrote:
> Does that still apply to
>
> view-source:http://man.openbsd.org/ksh
compared with a PDF version:-
http://chuzzlewit.co.uk/WebManPDF.pl/man:/1/ksh
Hi,
Steffen Nurpmeso wrote on Tue, Apr 25, 2017 at 08:19:21PM +0200:
> the HTML output of mandoc used repeated per-paragraph style
> directives and a CSS file, which caused enormous bloat, last
> time i tried.
Does that still apply to
view-source:http://man.openbsd.org/ksh
I spent a few week
At 2017-04-27T04:00:29+, Bjarni Ingi Gislason wrote:
> On Mon, Apr 24, 2017 at 11:41:22AM -0400, G. Branden Robinson wrote:
> > At 2017-04-24T16:22:37+0100, Ralph Corderoy wrote:
> > > .SM affect the next input line as it uses an input trap, `.it'. `\c'
> > > doesn't make an input line continu
Hi,
Steffen Nurpmeso wrote on Thu, Apr 27, 2017 at 02:21:10PM +0200:
> You have a notion of "callable" and "parsed", and you should be
> aware of that or you introduce errors which are hard to find.
Wrong. Just assume everything is callable. Actually, mandoc
warns if you use the name of a macr
"G. Branden Robinson" wrote:
Sorry for answering so late, my daily routine has shifted to night
again, almost sunset, and that really makes me frustrated.
|At 2017-04-25T20:19:21+0200, Steffen Nurpmeso wrote:
...
|>|> c. Show people a mapping from groff's "extended" man macro package to
|>|
Hi,
Bjarni Ingi Gislason wrote on Thu, Apr 27, 2017 at 04:00:29AM +:
> On Mon, Apr 24, 2017 at 11:41:22AM -0400, G. Branden Robinson wrote:
> > At 2017-04-24T16:22:37+0100, Ralph Corderoy wrote:
>>> .SM affect the next input line as it uses an input trap, `.it'. `\c'
>>> doesn't make an inpu
On Mon, Apr 24, 2017 at 11:41:22AM -0400, G. Branden Robinson wrote:
> At 2017-04-24T16:22:37+0100, Ralph Corderoy wrote:
> > .SM affect the next input line as it uses an input trap, `.it'. `\c'
> > doesn't make an input line continue to the next as far as input traps
> > are concerned; groff has
At 2017-04-26T09:27:56-0400, G. Branden Robinson wrote:
> > It seems to me that b) is fine, a) is very problematic because it
> > severely harms portability,
>
> You're making a testable assertion here.
>
> 1. Portability is not harmed if extended man macros are inlined in pages
>where portab
At 2017-04-26T15:03:33+0100, Ralph Corderoy wrote:
> Hi Branden,
>
> > http://code.swtch.com/plan9port/ is a 404 for me.
> > Do you have an up-to-date link?
>
> https://github.com/9fans/plan9port#readme
Gracias, seΓ±or! Some days I need someone to JFGTFM. ;-)
Regards,
Branden
signature.asc
D
The BitKeeper man page macros use this sort of construct a lot.
-Original Message-
From: "Doug McIlroy"
Sent: Tuesday, April 25, 2017 4:00pm
To: groff@gnu.org
Subject: Re: [Groff] Nesting font macros in man pages
> .TP
> .B \-scale \c
> .IR xfac [, yfac ]
Very
Hi Branden,
> http://code.swtch.com/plan9port/ is a 404 for me.
> Do you have an up-to-date link?
https://github.com/9fans/plan9port#readme
Cheers, Ralph.
At 2017-04-25T20:19:21+0200, Steffen Nurpmeso wrote:
> Btw., if you want really clean man(7) you should point people to
> the really good guys, e.g., the plan9port manuals are a phantastic
> example of minimalistic and pure pages.
I'd love to, as I'm the sort who's still excited by Plan 9 (and its
At 2017-04-25T16:52:20+0200, Ingo Schwarze wrote:
> G. Branden Robinson wrote on Tue, Apr 25, 2017 at 07:14:58AM -0400:
>
> > No, what I really want is a TP-ish macro that lets you break the tag
> > across multiple input lines, so the writer doesn't have to use font
> > escapes.
> >
> > If that m
> .TP
> .B \-scale \c
> .IR xfac [, yfac ]
Very clever. I wish I'd thought of it when I was editing
the v7 manual. Then it would have become a standard idiom.
Has nobody tried this during the nearly 40 years since?
Doug
Ingo Schwarze wrote:
|G. Branden Robinson wrote on Tue, Apr 25, 2017 at 07:14:58AM -0400:
...
|> If that means a new macro, I'm fine with that.
...
|For man(7), introducing new macros would be worse. There, it would
|utterly break portability because other implementations do exist,
Now i r
Hi,
G. Branden Robinson wrote on Tue, Apr 25, 2017 at 07:14:58AM -0400:
> No, what I really want is a TP-ish macro that lets you break the tag
> across multiple input lines, so the writer doesn't have to use font
> escapes.
>
> If that means a new macro, I'm fine with that.
I think that plan is
"G. Branden Robinson" wrote:
|At 2017-04-24T18:29:57+0200, Ingo Schwarze wrote:
...
|I entirely agree with the virtues of semantic of "presentation"-based
|markup. However, this could be mitigated by encouraging a consistent
|style in groff_man(7) itself. Some coordination with Michael Kerr
At 2017-04-25T07:04:27+0200, Ingo Schwarze wrote:
> Hi,
>
> G. Branden Robinson wrote on Mon, Apr 24, 2017 at 09:22:25PM -0400:
> > At 2017-04-24T18:29:57+0200, Ingo Schwarze wrote:
> >> G. Branden Robinson wrote on Mon, Apr 24, 2017 at 11:41:22AM -0400:
>
> >>> to the more readable (and, I submi
Hi,
G. Branden Robinson wrote on Mon, Apr 24, 2017 at 09:22:25PM -0400:
> At 2017-04-24T18:29:57+0200, Ingo Schwarze wrote:
>> G. Branden Robinson wrote on Mon, Apr 24, 2017 at 11:41:22AM -0400:
>>> to the more readable (and, I submit, more writable-by-the-novice):
>>>
>>> .TP
>>> .B \-scale \c
At 2017-04-24T18:29:57+0200, Ingo Schwarze wrote:
> Hi,
>
> G. Branden Robinson wrote on Mon, Apr 24, 2017 at 11:41:22AM -0400:
>
> > to the more readable (and, I submit, more writable-by-the-novice):
> >
> > .TP
> > .B \-scale \c
> > .IR xfac [, yfac ]
> > Multiply the horizontal and vertical w
Hi,
G. Branden Robinson wrote on Mon, Apr 24, 2017 at 11:41:22AM -0400:
> to the more readable (and, I submit, more writable-by-the-novice):
>
> .TP
> .B \-scale \c
> .IR xfac [, yfac ]
> Multiply the horizontal and vertical window size by
YIKES, that sounds like an absolutely terrible idea!
T
At 2017-04-24T16:22:37+0100, Ralph Corderoy wrote:
> .SM affect the next input line as it uses an input trap, `.it'. `\c'
> doesn't make an input line continue to the next as far as input traps
> are concerned; groff has .itc for that. So the .SM is over by the `)'.
That's exactly the hack I wa
Hi Branden,
> .SM
> .B IFS\^\c
> )
>
> I think the intention here was to get back to the normal-size roman
> font after "IFS" without introducing a stretchable space (hence \c)
> but still leave some room between the small bold IFS and the closing
> parenthesis, hance the hair space \^
45 matches
Mail list logo
