From mboxrd@z Thu Jan 1 00:00:00 1970 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 62683e7b for ; Fri, 14 Feb 2020 12:06:17 -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_AES_256_GCM_SHA384:256) (envelope-from ) id 1j2ePu-000850-6B; Fri, 14 Feb 2020 18:06:16 +0100 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 1j2ePs-0006lW-FV; Fri, 14 Feb 2020 18:06:12 +0100 Received: from athene.asta.kit.edu ([141.3.145.60] helo=athene.usta.de) by donnerwolke.usta.de with esmtp (Exim 4.84_2) (envelope-from ) id 1j2ePs-0007Uj-A9; Fri, 14 Feb 2020 18:06:12 +0100 Received: from localhost (athene.usta.de [local]) by athene.usta.de (OpenSMTPD) with ESMTPA id 71d8fff7; Fri, 14 Feb 2020 18:06:09 +0100 (CET) Date: Fri, 14 Feb 2020 18:06:09 +0100 From: Ingo Schwarze To: "Anthony J. Bentley" Cc: tech@mandoc.bsd.lv Subject: Re: Incorrect column count in lint messages Message-ID: <20200214170609.GF92189@athene.usta.de> References: <21953-1581656851.930227@-SgG.yrqY.5jf-> X-Mailinglist: mandoc-tech Reply-To: tech@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21953-1581656851.930227@-SgG.yrqY.5jf-> User-Agent: Mutt/1.12.2 (2019-09-21) Hi Anthony, Anthony J. Bentley wrote on Thu, Feb 13, 2020 at 10:07:31PM -0700: > Consider the following example: > > .Dd > .Sh DESCRIPTION > .Oo lorem ipsum dolor sit amet consectetur adipiscing elit sed do eiusmod \ > Ar Ns , Oc > > When run through mandoc -Tlint, this warning appears: > > mandoc: /tmp/foo.1:4:78: WARNING: skipping no-space macro > > The line number is correct, but the column count wrongly includes the > length of the previous line. That is very hard to fix because the trailing backslash requests joining both lines before further parsing, which is done very early between the read.c module and the roff(7) preprocessor. By the time the mdoc(7) parser gets to see the line, the information which parts of the line originally were on which input line is no longer available. I don't see any way of fixing this short of storing an input column number for every single character in the parse buffer. There are many more ways to get the input line preprocessed. They all mangle the column count, for example: $ mandoc -mdoc -W all .ds w longword .Em \*w Ns . mandoc: :2:14: WARNING: skipping no-space macro The "Ns" is in column 9, not column 14. I don't think it would be a good idea to even try to fix this. Preprocessing is not very widespread in well-written manual pages in the first place, even traling \ is usually best avoided (though there are a few unusual circumstances where it makes sense), and improving column numbers in messages eould hardly justify major complications of the code. Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv