Upstream maintainer talking here.
This utterly unhelpful.
First of all, please don't commit Debian-specific patches fixing
trivial and minor style issues in manual pages to the Debian packaging
systems. Report them upstream *instead* of bothering downstream,
and they will automatically get fixed after a normal release and
version update.
Second aspect, reporting such minor nits against an utterly outdated
release - the current release is 1.14.3, released more than half a
year ago, and there were three more releases in between - isn't all
that helpful either.
Third aspect, for some of the "issues", it is quite unclear to
me what Bjarni is doing. Having seen low-quality bug reports
from Bjani before, i doubt that he can explain it better, so please
don't bother.
Bjarni Ingi Gislason wrote on Sun, Mar 18, 2018 at 09:29:37PM +0000:
> mandoc: mandoc.1:838:4: STYLE: unterminated quoted argument
> mandoc: mandoc.1:852:4: STYLE: unterminated quoted argument
[...]
> mandoc: mandoc.1:2433:4: STYLE: unterminated quoted argument
> mandoc: mandoc.1:2441:4: STYLE: unterminated quoted argument
Cannot reproduce, even though i spent the time of extracting an
old tarball, building from it, and checking the file. The above
errors simply do not happen. Neither with the mandoc-1.13.3
release version nor with mandoc-current.
> Test nr. 2:
> Enable and fix warnings from 'test-groff'.
> Input file is /tmp/mandoc.1
> 'R' is a string (producing the registered sign), not a macro.
> chk_manuals: Output is from: test-groff -Tutf8 -b -e -mandoc -rF0 -t -w w -z
That makes no sense whatsoever. The file mandoc.1 doesn't even
use the man(7) language, it uses the mdoc(7) language, so there is
certainly no .R macro inside.
> troff: <standard input>:849: warning: can't find special character 'Lq'
> troff: <standard input>:849: warning: can't find special character 'Rq'
The file mandoc.1 cotains neither the string "Lq" nor "Rq".
> Test nr. 7:
> Change (or include a "FIXME" paragraph about) misused SI (metric)
> numeric prefixes (or names) to the binary ones, like Ki (kibi), Mi
> (mebi), Gi (gibi), or Ti (tebi), if indicated.
> If the metric prefixes are correct, add the definitions or an explanation
> to avoid misunderstanding.
>
> 2403:of 2^31 bytes (2 Gigabytes).
That is completely irrelevant. The full paragraph reads:
Unsupported features
*input too large*
(mdoc, man) Currently, mandoc cannot handle input files larger than its
arbitrary size limit of 2^31 bytes (2 Gigabytes). Since useful manuals
are always small, this is not a problem in practice. Parsing is aborted
as soon as the condition is detected.
Obviously, it doesn't matter at all whether these are GB or GiB,
it's just a rough hint for a human reader regarding the order of
magnitude of the limit. The largest real-world manuals are barely
larger than 1 Megabyte, e.g. perltoc(1).
Nothing to fix here.
> Test nr. 8:
>
> Protect a full stop (.) with "\&", if it has a blank (white-space) in front
> of or (ignoring transparent characters to the full stop) after it, and it does
> not mean an end of a sentence.
>
> 1654:The first argument, i.e. the name, is printed, but without subsequent
That is bogus advice.
The first argument, i.e.\& the name, is printed, ...
would be completely pointless.
That kind of escaping only makes sense when the abbreviation
happens to appear at the end of an input line.
> Test nr. 17:
> Change - to \- if it means a minus sign.
> 715:$ mandoc \-T lint \(gafind /usr/src -name \e*\e.[1-9]\(ga
That is true, and at some point in the future, i'm going to fix
these issues in the OpenBSD tree, including mandoc.
It's a known task, it was discussed at length on <gr...@gnu.org>,
where the discussion belongs, and i said that i'm going to do it.
But it can't be done overnight.
A patch fixing one out of 5000 files completely misses the point.
And no, please don't send a patch touching 5000 files either.
> Test nr. 20:
> Use a macro to change to the italic font, instead of \fI [1], if
> possible.
> The macros have the italic corrections, but "\c" removes them.
> [1] man-pages(7)
>
> 11:[\fB\-I\fR\ \fBos\fR=\fIname\fR]
> 12:[\fB\-K\fR\ \fIencoding\fR]
I have no idea what this is. A file called man-pages.* doesn't
even exist in the mandoc distribution. The content has some
similarities with the mandoc(1) manual page, but i haven't the
slightest idea what is going on here.
> Test nr. 24:
> Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a
> name for an option.
See test 17 above.
> Test nr. 26:
> Find a repeated word
> ! 123 --> the
That was in a source code comment(!) and was fixed almost two years
ago:
http://mandoc.bsd.lv/cgi-bin/cvsweb/term.c.diff?r1=1.256&r2=1.257
The file in question has 18 newer commits by now.
> Test nr. 27:
>
> Split lines longer than 80 characters into two or more
> lines. Apropriate break points are the end of a sentence or subordinate
> clause.
>
> mandoc.1: line 995 length 95
Obviously a bogus report. Such a line does not exist.
$ grep -E '.{79}' mandoc.1
$ grep -E '.{78}' mandoc.1
.D1 Nm Ns : Ar file : Ns Ar line : Ns Ar column : level : message : macro args
A table layout specification contains more than two consecutive vertical bars.
the characters following it are used as the arguments to the request or macro.
The longest lines are exactly 78 characters.
> --- mandoc.1 2017-09-18 14:10:53.000000000 +0000
> +++ mandoc.1.new 2018-03-18 19:28:01.000000000 +0000
> @@ -120,7 +120,7 @@ With
> all input files are interpreted as
> man(7).
> By default, the input language is automatically detected for each file:
> -if the the first macro is
> +if the first macro is
> \fB\&Dd\fR
> or
> \fB\&Dt\fR,
Fixed four months ago.
So, there is not a single valid point in this report.
I suggest to close it as invalid.
Yours,
Ingo
