Re: [9front] werc/apps/wman botches some man page links

Re: [9front] werc/apps/wman botches some man page links

[sl]

Counterpoint:

If we hack nroff to solve a wman problem, now wman needs 9front.

sl

Re: [9front] werc/apps/wman botches some man page links

[Ethan A. Gardener]

On Wed, Aug 15, 2018, at 2:44 PM, Stanley Lieber wrote:
> On Aug 15, 2018, at 9:41 AM, Stanley Lieber <sl@stanleylieber.com> wrote:
> 
> > IMO, the approach that makes the most sense in this case is to \- escape the troff sources of the problem man pages.
> 
> It would probably still be wise to, in addition, still try to address 
> this somehow in wman itself. Not every wman user is willing or able to 
> modify whatever man pages it is used to display.

I think wman could filter the troff source before passing it to nroff.
This substitution might do:

s/([a-z]+)(-[a-z]+\([0-9]\))/\1\\\2/g

It's untested because I'm not with it today.  
Can't find the mail with the problem statement 
or previous solutions.

Re: [9front] werc/apps/wman botches some man page links

[Stanley Lieber]

On Aug 15, 2018, at 9:41 AM, Stanley Lieber <sl@stanleylieber.com> wrote:

> IMO, the approach that makes the most sense in this case is to \- escape the troff sources of the problem man pages.

It would probably still be wise to, in addition, still try to address this somehow in wman itself. Not every wman user is willing or able to modify whatever man pages it is used to display.

sl

Re: [9front] werc/apps/wman botches some man page links

[Stanley Lieber]

On Aug 15, 2018, at 9:08 AM, Ethan A. Gardener <eekee57@fastmail.fm> wrote:
> 
>> On Tue, Aug 14, 2018, at 5:40 PM, sl@stanleylieber.com wrote:
>> Counterpoint:
>> 
>> If we hack nroff to solve a wman problem, now wman needs 9front.
> 
> Counter-counterpoint:  It's not just a wman problem, it's a plumber problem too.  Does that mean the plumber will need 9front? :)

The point about werc is that most of its users are not even running Plan 9, and we only control one fork of Plan 9 tools for UNIX, which is run by approximately one werc user (me, for openbsd.stanleylieber.com). So, fixing wman by modifying one possible underlying OS doesn’t fix wman, because wman runs everywhere.

I would like for the plumbing issue to be addressed as well.

IMO, the approach that makes the most sense in this case is to \- escape the troff sources of the problem man pages.

sl

Re: [9front] werc/apps/wman botches some man page links

[Ethan A. Gardener]

On Tue, Aug 14, 2018, at 5:40 PM, sl@stanleylieber.com wrote:
> Counterpoint:
> 
> If we hack nroff to solve a wman problem, now wman needs 9front.

Counter-counterpoint:  It's not just a wman problem, it's a plumber problem too.  Does that mean the plumber will need 9front? :)

Re: [9front] werc/apps/wman botches some man page links

[sl]

>> 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)).

[...]

> 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?

This sounds reasonable to me.

Anyone else have an opinion?

sl

Re: [9front] werc/apps/wman botches some man page links

[Travis Moore]

> 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

Re: [9front] werc/apps/wman botches some man page links

[Stanley Lieber]

On Aug 13, 2018, at 4:26 AM, Travis Moore <umbraticus@prosimetrum.com> wrote:
> 
> if you insert a backslash before the offending
> hyphen in the source it prevents the split.
> 
> not sure if this is helpful, but perhaps it
> shouldn't be splitting in the regular text
> output either...
> 
> from /sys/doc/troff.ps!25 :
> 
>    Words that contain hyphens ... are
>    always subject to splitting after
>    those characters, whether automatic
>    hyphenation is on or off.
> 
> so you can't just turn off hyphenation...

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.

I’m reluctant to bin the markdown-transiting
version because it’s output includes less
tags and is less likely to trigger CSS
convulsions.

sl

Re: [9front] werc/apps/wman botches some man page links

[Travis Moore]

if you insert a backslash before the offending
hyphen in the source it prevents the split.

not sure if this is helpful, but perhaps it
shouldn't be splitting in the regular text
output either...

from /sys/doc/troff.ps!25 :

	Words that contain hyphens ... are
	always subject to splitting after
	those characters, whether automatic
	hyphenation is on or off.

so you can't just turn off hyphenation...

umbraticus

Re: [9front] werc/apps/wman botches some man page links

[Eckard Brauer]

[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

Am Thu, 9 Aug 2018 21:21:11 -0400
schrieb sl@stanleylieber.com:

> Previous message garbled.  Full article here:
> 
> 	http://plan9.stanleylieber.com/werc/apps/wman/linewraps
> 
> sl

Writing that with some reservation because currently only using
plan9port (will have to repair my p9 system):

When setting RS to \0 awk is taking paragraphs separated by empty lines
each time, so I simply iterated over a whole paragraph each time.
Problems are, that (1) gsub doesn't have sub-patterns and gensub isn't
available, so I had to do all by hand:

awk -v RS='\0' 'function stripoff(str, num) {
                        str = substr(str, num, length(str)-num+1)
                        sub("^  *", "", str)
                        return str }
                /[a-z]-\n  *[a-z]/ {
                        for (s=$0; i=index(s, "-\n "); s=stripoff(s, i+2)) {
                                printf("%s",substr(s,1,i-1)) }
                        print s "\n"
                        next }
                1'

So maybe it's also possible to integrate the following sed and awk
stuff there - I'd try it if the above is of any help.


-- 
:)

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [9front] werc/apps/wman botches some man page links

[Ethan A. Gardener]

On Fri, Aug 10, 2018, at 2:21 AM, sl@stanleylieber.com wrote:
> Previous message garbled.  Full article here:
> 
> 	http://plan9.stanleylieber.com/werc/apps/wman/linewraps
> 
> sl

i felt like doing things which annoy me today, so:
http://okturing.com/src/4870/body
i think the regexps are broken, 
but i'm no longer in the mood.

this problem also affects plumbing plain text. 
it would be better to fix troff or an or whatever, 
or even hack the page sources.


-- 
The lyf so short, the craft so long to lerne. -- Chaucer