Re: Proposal to remove catman(8)

[Kamil Rytarowski <kamil%netbsd.org@localhost>]

On 10.11.2020 23:04, Robert Elz wrote:
>     Date:        Tue, 10 Nov 2020 19:28:41 +0100
>     From:        Kamil Rytarowski <kamil%netbsd.org@localhost>
>     Message-ID:  <c4db1f9d-85ee-f90a-2ea0-c1a6448b39ca%netbsd.org@localhost>
> 
>   | I hope this is a typo, and not the indication that you forgot how to use
>   | the cat-pages at all and miss a computer to cross-check how these files
>   | are named.
> 
> As in my reply to Mouse, I just didn't bother to check, I did what I
> did, and tested it, and it worked.   But:
> 

.0 is since ever. I couldn't grep any other suffixes in projects, thus
one BSD4.3 Reno snapshot has a bunch of files with custom endings.
Assuming that this knowledge is from Reno times, it was not refreshed
since 1990.

cat-pages concept is so legacy that as far as I can tell, nobody
bothered to standardize it in any specification in late 80ties or later.

>   | cat-pages always finish with .0
> 
> that works even better.   Even more readable (I guess there's a difference
> in the method used to display the file).
> 

So you just confirmed to have a lot of opinions and just started to
(re)learn how to use cat-pages at all...

I inform you that you were happy to render your cat page with mandoc(1).

>   | Personally, I miss ditroff, as I have got some documentation in this
>   | format that is not formatted promptly with other tools I checked.
> 
> Huh?   There's very little that ditroff (which is just a troff implementation
> with a more general set of output drivers than the original troff had, that's
> the "di" - device independant) can format that groff does differently (groff
> has many extensions, but if they're not being used, that's harmless).
> 
> You do need the appropriate macros (whatever the source assumes) of course.
> And you need the appropriate pre-processors (if any are used).
> 

groff is not compatible.

>   | I didn't differentiate MKCATPAGES=yes from catpages support.
> 
> Exactly.   That's what various people have been telling you.
> 

I am surprised that the proposal to remove MK${FOO} is read as removal
of the Makefile conditionals and keep ${FOO} in the base. With that
bizarre interpretation the whole proposal renders into useless idea.

I would be very surprised to interpret that e.g. proposal to remove
MKX11 would not mean to remove X11 from the base but to enable it by
default.