Re: Proposal to remove catman(8)

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

On 10.11.2020 12:59, Robert Elz wrote:
>     Date:        Tue, 10 Nov 2020 11:14:12 +0100
>     From:        Kamil Rytarowski <kamil%netbsd.org@localhost>
>     Message-ID:  <ca45be8b-018c-ef0f-3330-14e4785eb851%netbsd.org@localhost>
> 
>   | If you still can find any man-page that is unsupported by mandoc, please
>   | let me know and I will report it.
> 
> That was done (by someone else, sorry, I have forgotten who that was)
> earlier in this thread.   groff_char(7)   Because it is an externally
> maintained man page, we cannot just alter its format, and I really don't
> think you're going to convince anyone to make mandoc handle:
> 
>   .  di CC
>   .  ie c\\$3 \{\
>   .    nop \\&\\$3\c
>   .    \" The \x values assure that oversized symbols don't
>   .    \" overlap vertically.  The constant 1.5p is heuristic.
>   .    nop \x'(\w'('*0 - ((\\n[.cht]u - \\n[rst]u - 1.5p) >? 0))'\c
>   .    nop \x'((\\n[.cdp]u + \\n[rsb]u - 1.5p) >? 0)'\c
>   .    nop \h'(\\n[c1]u - \\n[.k]u)'\\*[CH]\c
>   .    nop \h'(\\n[c2]u - \\n[.k]u)'\\$2\c
>   .  \}
>   .  el \{\
>   .    nop (N/A)\c
>   .    nop \h'(\\n[c1]u - \\n[.k]u)'\\*[CH]\c
>   .  \}
>   .  nop \h'(\\n[c3]u - \\n[.k]u)'\\$4\c
>   .  nop \h'(\\n[c4]u - \\n[.k]u)'\\$5\c
>   .  br
>   .  di
> 
> [that's just one piece of a larger macro definition in that page]
> 
> On the other hand, after a simple
> 
> 	groff -man -T ascii /usr/share/man/man7/groff_char.7 \
> 			  > /usr/share/man/cat7/groff_char.7
> 
> I now have a man page I can (better anyway) read.   If I had the time
> to read up on all the groff -T options, it would probably be possible
> yo make something quite readable.
> 

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. It's not a bad thing to forget how to use them, but I'm
unsure whether the reason of blocking the removal (post-removal) is an
optimal motivation for relearning. cat-pages always finish with .0
(unless compressed) and that way they are integrated into man.conf(5).

Other tools like groff and nroff are around and not intended to be removed.

Personally, I miss ditroff, as I have got some documentation in this
format that is not formatted promptly with other tools I checked. If
someone has a good sources of ditroff, I support the import to src/.

I've reported to the mandoc upstream the groff_char(7).

> 
>   | Removal of the whole cat-pages support was implied
> 
> It wasn't.
> 

I wrote:

"I propose to drop the support for MKCATPAGES=yes. catpages are
preformatted .txt files that happen to contain manual pages and are
cat(1)able.

Over the past more than 5 years, I was the only person reporting any
fallout and fixing the regressions in the MKCATPAGES=yes build failures.

I'm going to switch to dynamic manual pages formatting through mandoc(1)
as superior, allowing to tune the behavior of the display.
"

I didn't differentiate MKCATPAGES=yes from catpages support. I also
wrote explicitly to use dynamic manual pages afterward. But I accept
that I could be ambiguous in the proposal.

>   | and intended in my initial proposal.
> 
> That may have been, but that intent wasn't conveyed.
> 
>   | This was intended to be removed too. Also what's the point of catman(8)
>   | if cat dirs were intended to be gone?
> 
> None, but those dirs should not be gone.   If I didn't have them, I wouldn't
> have been able to to the command above, and that's a useful thing to be able
> to do (as is the ability to install a "man page" when all you have is an
> ascii hand-formatted text file).    And as long as the dirs remain, catman(8)
> remains potentially useful.
> 

OK. We have agreed that catman(8) is potentially useful with the cat
dirs available.

>   | The cat pages are passed through cat(1) and thus cannot be (easily)
>   | reformatted dynamically.
> 
> You keep repeating that as if this is news.   You're not understanding
> that I don't care.   I don't want them reformatted dynamically, or at all.
> 

I agree that cat-pages are not intended to be regenerated.

>   | I don't want to drag regular users to mailing lists.
> 
> That's understandable, but you could at least delete the e-mail addresses
> and names, and forward the actual complaint (along with a translation if
> that is likely to be needed).
> 

This was already phrased in the original MKCATPAGES mail and repeated;
the wanted feature is to have MANWIDTH and it needs reformatting the
pages on the fly. This conflicts with the pregenerated pages concept
which I find no longer relevant any more for the original reasons (such
as performance on multiuser vax780 from 1977? or coherent unix operating
in a 2 MBs of RAM).

FreeBSD implements it by disabling cat-pages behind the scenes. I find
this approach waste of time in 2020. It could be maybe tentative in 2011
when implemented in FreeBSD.

>   | I was asked by mrg@ to revert the MKCATPAGES removal and add a new
>   | proposal that is more precise.
> 
> Yes, I saw that, and that you agreed, that is a step forward (though I
> personally have no problem with deleting the MKCATPAGES build option, and
> the relevant set list entries).   But only that much.
> 

I keep having some spurious fallout in builds and the re-addition (seems
to be after sqlite3 changes) and I keep having constant build failures.
I will add it.

> kre
>