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=2.7 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FROM_SUSPICIOUS_NTLD,PDS_OTHER_BAD_TLD,T_SCC_BODY_TEXT_LINE, T_TVD_MIME_EPI autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 5969 invoked from network); 5 Jun 2022 20:16:44 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 5 Jun 2022 20:16:44 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id cef8f58e for ; Sun, 5 Jun 2022 15:16:41 -0500 (EST) Received: from tarta.nabijaczleweli.xyz (139-28-40-42.artus.net.pl [139.28.40.42]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 691e239d for ; Sun, 5 Jun 2022 15:16:40 -0500 (EST) Received: from tarta.nabijaczleweli.xyz (unknown [192.168.1.250]) by tarta.nabijaczleweli.xyz (Postfix) with ESMTPSA id C7FE32296; Sun, 5 Jun 2022 22:16:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nabijaczleweli.xyz; s=202205; t=1654460198; bh=56JbOIXKGJYboSb3GXcTIrqsK07DQn19OIic5fscDqY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ACXkSzSUDXeSgahcCltnNNzwtxX/IxFDWskdNm/9rhkWgbwP3rDCiwAMG81AmycND xJcCZnZeONf41TwjBcd4u5MRqv38sX3ht0LmfKTm5zXyjy1ZX33fg+CDJovuymbZvg gBRxFouY1cYqB2R2pHbDXX0+9si4LcUXp5iN5xUzHXUH9HWrh2qfdr4xa6rmSwr1/I /RgrbdmimquUDHNCzkBQ2tKxlBlE72L2YOi6XHrphb8MyPCr/i8/c6N9UVA79/HMsp kf0LQ6YbRkA/y5g6M5NjmQu1tejcVr3b1EHDNoKSYcYfX5cJt+7BmHjdo+rkbofOs+ aQKiCeN69/P6mylwLskLHIyM/eSMKMvelHWa8TE+W3UKkieCa9dJakoptskVackmZD I5FlB+K9/uT/rUE7bZB0AQORjbsYWcO6zxOqZ8nnwFFqk3GJ28bMECHON0U/QnwYoW SPF4CzI1ScSIx4D1MFfKIQ3LW6V+POx6Bf+ZGEpBl5XNPk7/pg/7CDiOVu9UnNMuvm qD719wmNeU7rg79yFPikjtGt5uNT6hujYZImEh6Bkpb+5NUIic3jen+bL7QHT8pdtf DfMAnnMtdJJUNBnAOjURFtmp5jF4LAtoKXTVi55tLdK9aj9ybvpFSwtXW8Z8/m4PIr q0X/TFpreaLs8HQkDxNHOAGU= Date: Sun, 5 Jun 2022 22:16:37 +0200 From: =?utf-8?B?0L3QsNCx?= To: Ingo Schwarze Cc: discuss@mandoc.bsd.lv Subject: Re: .Bl -tag -width ".mdoc macro" not recognised sometimes(?) Message-ID: <20220605201637.yaxcaveqsyf7da4d@tarta.nabijaczleweli.xyz> References: <20220605161635.chte3k2gotoceerf@tarta.nabijaczleweli.xyz> <20220605182824.xlnxr4tfb63yuddi@tarta.nabijaczleweli.xyz> X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ktu3isxiuqnnwdpm" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20220429 --ktu3isxiuqnnwdpm Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! On Sun, Jun 05, 2022 at 09:43:13PM +0200, Ingo Schwarze wrote: > Nab wrote on Sun, Jun 05, 2022 at 08:28:24PM +0200: > > On Sun, Jun 05, 2022 at 07:55:39PM +0200, Jan Stary wrote: >=20 > >> On Jun 05 18:16:35, nabijaczleweli@nabijaczleweli.xyz wrote: > >> Quoting mdoc(7): > >>=20 > >> The -width and -offset arguments accept > >> macro names as described for Bd -offset, > >> scaling widths as described in roff(7), > >> or use the length of the given string. > >>=20 > >> Is your -width a macro name (such as Ds) as descibed for -offset? No. > >> Is it a scalinbg width as described in roff(7)? No. > >> Apparently, mandoc uses the length of the given string then. > >> AFAICT, that's what you told it to do. >=20 > > Ah, yeah, that's fair; this is, apparently, a groffism: > > If =E2=9F=A8string=E2=9F=A9 starts with a =E2=80=98.=E2=80=99 (dot) i= mmediately followed by a valid > > -mdoc macro name, interpret =E2=9F=A8string=E2=9F=A9 and use the widt= h of the result. >=20 > I think you are right that this is a groff extension. > I did quick testing with Cynthia's final version of the 4.4BSD mdoc(7) > macros and they don't appear to support a full macro line (including > the leading dot) as a -width argument, or rather, they just take the > string length of the line, like mandoc(1) does. My quick skim of 4.4BSD-Lite2 mdoc aligns with this, yeah. > Then again, Cynthia's version of the macros is very old and mandoc(1) > mostly aims for groff compatibility. So supporting this feature is > desirable. But it looks seriously complicated given the existing > mandoc code structure. So it's certainly not a short-term task and > maybe not even feasible in the medium term but rather a long-term > goal. Besides, the priority is moderate at best because i don't > recall having seen this often in practice. 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). > > Almost all lists in this document use this option. > I must admit i share Jan's curiosity in which real-world document > this feature is used. This whole segment is taken directly from groff_mdoc(7) off Bullseye, and I use it for my manuals (although that usually matches the natural text width well enough; this tr example is an edge-case). > In general, if a feature is used in important, widely used manual > pages, that raises the priority of supporting it - even though in > this case, admittedly, even a very high priority would help little > to overcome the significant difficulty of implementing it. Not that it's the be-all end-all, but DCS[1] says: 116 files grepped (95 results) (if you filter by src:groff, that accounts for 65 files grepped (65 results)) this includes mandoc: -- >8 -- mdocml_1.14.6-1/TODO - When the -width string contains macros, the macros must be rendered before measuring the width, for example .Bl -tag -width ".Dv message" in magic(5), located in src/usr.bin/file, is the same as -width 7n, not -width 11n. -- >8 -- continuing from CVS: -- >8 -- The same applies to .Bl -column column widths; reported again by Nicolas Joly Thu, 1 Mar 2012 13:41:26 +0100 via wiz@ 5 = Mar reported again by Franco Fichtner Fri, 27 Sep 2013 21:02:28 +0200 reported again by Bruce Evans Fri, 17 Feb 2017 21:22:44 +0100 via bapt@ loc *** exist *** algo *** size ** imp *** -- >8 -- There's also one result for -column ". =66rom manpages-l10n. Most of them are relatively simple: .Cm restrict_loggedin_tty Ns =3D Ns Ar ttyglob* .Ev DNSDB_API_KEY , APIKEY .Fl bullet this affects them, but, well, not much (45/30, 26/21, 10/7, respectively), my 59/13 is, decidedly, a 3.26-fold edge-case. I'd say that the shorthand assessment from the TODO and yours, above, are unfortunately accurate. [1]: https://codesearch.debian.net/search?q=3D-width+%22.&literal=3D1 > Yours, > Ingo Best, =D0=BD=D0=B0=D0=B1 --ktu3isxiuqnnwdpm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfWlHToQCjFzAxEFjvP0LAY0mWPEFAmKdDyMACgkQvP0LAY0m WPF+vxAAorUsXfLNm/5mUQguZbW6GqJZjzyZKsvxn32BdqW4w9j/aXwGEdBPecbz Bk4HBZZmGWnWDl/a8WEojQVhn5VwOFvfnKMyIMQvrXM8yfWqgrfzexw9T7QxmIgf tn8cebri8dgEC8fi8p0Nr0Z9w1YdkER31Xv2GsD/QFbnejeYzurTOqCF0Qo+p7jg 5VWYcEG/7+buhujuCWv+s1Hpd2YGDXPic5VgMKTyzIMTTcFCHbNbb8UghE5lBRzW QDeEU1tLR9dUFrSr0jFFAl5BOumBh+lbmyPxK2wIGd/yp1cOuRyrpq732rYoB+g1 TFJev2J5wVaWLCll1iMNlkRAwktfc7hXhy+RLqfv5MoDIOX4BRG1m1o2Qs4zqiCk pOA1ravDinOgpRzDIDDmBgz1D9Ewvd4B/zTi50ac/pTtYWbfC/mN8GyXJVzhBc0/ uC1AZO9GkK4CY/yZDTLWyrZ3eUvmQt/kyyjXDJMlSRNrAWPVDtG7tfOwmGCc91q8 beanEMn6/ZH1L66mj7T+46XUmEbCBKmBbloyB5EiE7VI3DeT/7Y2lKle4nXBax8i K3NjMCh8q2ZYrXea5N4o09BAPs8A+Yx73kKRuIa2RVDdh5zjKoOwNF8OwLFepm3d ho0C2zQDM895mSf38ZMx61xMgrmW20LHaX12q9nS1/ZqIjlCaso= =LgtF -----END PGP SIGNATURE----- --ktu3isxiuqnnwdpm-- -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv