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=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24831 invoked from network); 28 Mar 2021 20:37:05 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 28 Mar 2021 20:37:05 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 33048528 for ; Sun, 28 Mar 2021 15:37:01 -0500 (EST) Received: from scc-mailout-kit-01.scc.kit.edu (scc-mailout-kit-01.scc.kit.edu [129.13.231.81]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id d6c5a775 for ; Sun, 28 Mar 2021 15:37:00 -0500 (EST) Received: from hekate.asta.kit.edu ([141.3.145.153] helo=hekate.usta.de) by scc-mailout-kit-01.scc.kit.edu with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id 1lQc9a-0004T5-MZ; Sun, 28 Mar 2021 22:36:59 +0200 Received: from donnerwolke.asta.kit.edu ([141.3.145.61] helo=donnerwolke.usta.de) by hekate.usta.de with esmtp (Exim 4.92.2) (envelope-from ) id 1lQc9Y-0006X5-O3; Sun, 28 Mar 2021 22:36:56 +0200 Received: from login-1.asta.kit.edu ([141.3.145.72]) by donnerwolke.usta.de with esmtp (Exim 4.84_2) (envelope-from ) id 1lQc9Y-00067j-KE; Sun, 28 Mar 2021 22:36:56 +0200 Received: from schwarze by login-1.asta.kit.edu with local (Exim 4.92) (envelope-from ) id 1lQc9Y-00030d-JT; Sun, 28 Mar 2021 22:36:56 +0200 Date: Sun, 28 Mar 2021 22:36:56 +0200 From: Ingo Schwarze To: "Anthony J. Bentley" Cc: tech@mandoc.bsd.lv Subject: Re: Improper formatting of table with T& Message-ID: References: <36636-1615006453.870094@W8oS.rk2z.-A1C> X-Mailinglist: mandoc-tech Reply-To: tech@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <36636-1615006453.870094@W8oS.rk2z.-A1C> Hi Anthony, Anthony J. Bentley wrote on Fri, Mar 05, 2021 at 09:54:13PM -0700: > mairix(1) contains this table: > > .TS > box tab(&); > lb | lb | lb | lb. > letter & short for & example & meaning > = > .T& > l | l | l | l. > d & days & 3d & 3 days > w & weeks & 2w & 2 weeks (14 days) > m & months & 5m & 5 months (150 days) > y & years & 4y & 4 years (4*365 days) > .TE > > groff renders it like so: > > +--------+-------------+-----------+-----------------------+ > |letter | short for | example | meaning | > +--------+-------------+-----------+-----------------------+ I consider this line a bug in groff; it should be +========+=============+===========+=======================+ like with mandoc. The groff tbl(1) manual page says: If a data line consists of only ‘_’ or ‘=’, a single or double line, respectively, is drawn across the table at that point; ... If you actually wanted "+--------+------ ...", you would have to specify letter & short for & example & meaning - i.e. a dash rather than an equal sign after the header data. Do you agree? > |d | days | 3d | 3 days | > |w | weeks | 2w | 2 weeks (14 days) | > |m | months | 5m | 5 months (150 days) | > |y | years | 4y | 4 years (4*365 days) | > +--------+-------------+-----------+-----------------------+ > > mandoc renders it similarly, but bolds both the header's bottom > border and the first line following (the 'days' line): > > +--------+-------------+-----------+-----------------------+ > |letter | short for | example | meaning | > +========+=============+===========+=======================+ > |d | days | 3d | 3 days | The text in this line being bold looks like a mandoc bug to me. The author's intention clearly is to use the "l | l | ..." format without the b modifiers. > |w | weeks | 2w | 2 weeks (14 days) | > |m | months | 5m | 5 months (150 days) | > |y | years | 4y | 4 years (4*365 days) | > +--------+-------------+-----------+-----------------------+ > > I couldn't find any explanation in our tbl(7) page of what T& does, > although it's mentioned briefly in the "Layout" section. We should > probably document it somewhere. I admit the documentation is terse, it says in our tbl(7): The table layout follows an Options line or a roff(7) TS or T& macro. So "l | l | l | l" is not data but a layout line even though it occurs after the first data line. How do you think should the wording be improved for additional clarity, such that it doesn't remain too terse but doesn't turn wordy and cumbersome either? I guess an improvement is likely possible. Writing the table as .TS box tab(&); lb | lb | lb | lb l | l | l | l. letter & short for & example & meaning = d & days & 3d & 3 days [...] would be equivalent, shorter and simpler, but that's no excuse for mandoc misrendering. So, here is a candidate patch. When looking for the last layout row used, we need to look at the layout row used for the previous data line containing data, not at the previous data line outright, which might be a horizontal ruler (as it is in this case). If it is, do not restart from the first layout row but still proceed to the next data row, which in this case was just read from T&. Does it work for you? If so, is it currently OK to commit to OpenBSD, or is there something i should pay attention to, such as release preparations or anything else that might be relevant? I must admit i'm a bit out of the loop right now - my fault, sorry for that. Some many insects - winter must be fading. Yours, Ingo Index: tbl_data.c =================================================================== RCS file: /cvs/src/usr.bin/mandoc/tbl_data.c,v retrieving revision 1.40 diff -u -p -r1.40 tbl_data.c --- tbl_data.c 11 Jan 2020 20:48:13 -0000 1.40 +++ tbl_data.c 28 Mar 2021 20:25:35 -0000 @@ -242,10 +242,11 @@ tbl_data(struct tbl_node *tbl, int ln, c struct tbl_cell *cp; struct tbl_span *sp; - rp = (sp = tbl->last_span) == NULL ? tbl->first_row : - sp->pos == TBL_SPAN_DATA && sp->layout->next != NULL ? - sp->layout->next : sp->layout; - + for (sp = tbl->last_span; sp != NULL; sp = sp->prev) + if (sp->pos == TBL_SPAN_DATA) + break; + rp = sp == NULL ? tbl->first_row : + sp->layout->next == NULL ? sp->layout : sp->layout->next; assert(rp != NULL); if (p[1] == '\0') { -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv