From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from asquith.prosimetrum.com ([125.236.209.157]) by ewsd; Tue Aug 14 00:48:48 EDT 2018
Message-ID: <0DD69EF566814D200356382A0279A190@prosimetrum.com>
From: Travis Moore <umbraticus@prosimetrum.com>
Date: Tue, 14 Aug 2018 16:49:42 +1200
To: 9front@9front.org
Subject: Re: [9front] werc/apps/wman botches some man page links
In-Reply-To: 042D6631-697B-420C-B44B-ABB6CD7DE48C@stanleylieber.com
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: generic leveraged CSS high-performance element frontend 

> I think the best solution is to insert a newline
> immediately after the man page link, wherever
> it may fall. This isn’t perfect but it’s better than
> having one infinitely long line sticking out of
> an otherwise consistently formatted section.

Sorry, I think I was unclear.  What I mean is
if, eg, you change /sys/man/8/venti:319 to read:

.IR venti\-fmt (8)).

then it won't break on the hyphen and the string
will be moved to the next line, like this:


	were formatted with fmtarenas or fmtisect (see
	venti-fmt(8)). In particular, only the configuration needs

which will look better than breaking after the
string, and then markdown filter can be applied
as usual...

My other point was that perhaps these strings
shouldn't be broken in normal nroff output
anyway. I mean, it breaks plumbing the string,
which is kind of the whole point of the cmd(#)
format..., so fixing it in the source is
perhaps justified?

if you grep -c '^\.IR.*-.*\(' /sys/man/*/*
you can see that there aren't that many, and
they're all of the pesky venti-x variety..

umbraticus