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: > > >> On Jun 05 18:16:35, nabijaczleweli@nabijaczleweli.xyz wrote: > >> Quoting mdoc(7): > >> > >> 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. > >> > >> 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. > > > Ah, yeah, that's fair; this is, apparently, a groffism: > > If ⟨string⟩ starts with a ‘.’ (dot) immediately followed by a valid > > -mdoc macro name, interpret ⟨string⟩ and use the width of the result. > > 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 ". from manpages-l10n. Most of them are relatively simple: .Cm restrict_loggedin_tty Ns = 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=-width+%22.&literal=1 > Yours, > Ingo Best, наб