On 10.11.2020 12:59, Robert Elz wrote:
> Date: Tue, 10 Nov 2020 11:14:12 +0100
> From: Kamil Rytarowski <ka...@netbsd.org>
> Message-ID: <ca45be8b-018c-ef0f-3330-14e4785eb...@netbsd.org>
>
> | 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
>
