From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15086 invoked from network); 6 Jun 2022 10:08:11 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 6 Jun 2022 10:08:11 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 7350a7fe for ; Mon, 6 Jun 2022 05:08:09 -0500 (EST) Received: from scc-mailout-kit-02.scc.kit.edu (scc-mailout-kit-02.scc.kit.edu [129.13.231.82]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 0de51166 for ; Mon, 6 Jun 2022 05:08:08 -0500 (EST) Received: from hekate.asta.kit.edu ([2a00:1398:5:f401::77]) by scc-mailout-kit-02.scc.kit.edu with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (envelope-from ) id 1ny9eY-005Lpk-Om; Mon, 06 Jun 2022 12:08:07 +0200 Received: from login-1.asta.kit.edu ([2a00:1398:5:f400::72]) by hekate.asta.kit.edu with esmtp (Exim 4.94.2) (envelope-from ) id 1ny9eW-005cae-K9; Mon, 06 Jun 2022 12:08:05 +0200 Received: from schwarze by login-1.asta.kit.edu with local (Exim 4.92) (envelope-from ) id 1ny9eX-0003RD-0P; Mon, 06 Jun 2022 12:08:05 +0200 Date: Mon, 6 Jun 2022 12:08:05 +0200 From: Ingo Schwarze To: nabijaczleweli@nabijaczleweli.xyz Cc: discuss@mandoc.bsd.lv Subject: Re: .Bl -tag -width ".mdoc macro" not recognised sometimes(?) Message-ID: References: <20220605161635.chte3k2gotoceerf@tarta.nabijaczleweli.xyz> <20220605182824.xlnxr4tfb63yuddi@tarta.nabijaczleweli.xyz> <20220605201637.yaxcaveqsyf7da4d@tarta.nabijaczleweli.xyz> X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220605201637.yaxcaveqsyf7da4d@tarta.nabijaczleweli.xyz> Hi Nab, Nab wrote on Sun, Jun 05, 2022 at 10:16:37PM +0200: > It's /incredibly/ useful for printing to PDF (and replaces banging out > the fonts and funny spaces manually in the -width argument), > but the value add for nroff is little (since every character in every > font is the same size; still pretty nice to not have to manually render > the macros though). Sure, i understand why you want to maintain a single mdoc(7) source that yields good results with all of the following processors: * groff -T pdf * groff -T utf8 * mandoc -T utf8 * mandoc -T html After all, that's the point of output-device-independent markup, isn't it? > This whole segment is taken directly from groff_mdoc(7) off Bullseye, Ouch. People *will* see it there and imitate it, which does rise the priority even more, quite apart from FreeBSD also needing it. I'm already planning to fix the simple case of having a *single* macro at the beginning in the not-to-distant future (which i classified as "loc * exist * algo * size * imp ***"). Maybe there is also some way to discard child macros in the middle without implementing a full diversion style solution (which i classified as "loc *** exist *** algo *** size ** imp ***"). We shall see... [...] > this includes mandoc: > -- >8 -- > mdocml_1.14.6-1/TODO My memory was never particularly good, but it looks like it is getting worse... :-/ Which only makes keeping the TODO file well-maintained more important. > [1]: https://codesearch.debian.net/search?q=-width+%22.&literal=1 I regularly use CDN when working on library code written in C, but it didn't so far occur to me that it's just as useful to look for documentation markup in mdoc(7) and man(7). Thanks for that idea! Yours, Ingo -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv