groff or mdoc [bug or feature]: mdoc warning: Empty input line #xxxx

[linda w.]

I don't know if this would officially be a bug or a feature.
I believe it would be best addressed in groff (or, possibly, mdoc macro).

~> groff -v
  GNU groff version 1.17.2
  ...(c)...
  called subprograms:
  GNU troff (groff) version 1.17.2
  GNU grops (groff) version 1.17.2

Distributed with SuSE 8.1 (current).  (same problem in some earlier
distros).
Found, first by:

  ~> man named.conf

Duplicable (for values -Tutf8 or -Tlatin1) via:

  ~> gunzip < /usr/share/man/man5/named.conf.5.gz| \
     groff -mandoc -Tutf8 - | less

---
        Problem input seems innocuous, ex:

.Dd January 7, 1999
.Dt NAMED.CONF 5
.Os BSD 4
                                        ## blank line in source, generates 
warning
.Sh NAME
.Nm named.conf

        Perhaps there is a special reason for warning people about blank
lines in a source file that are conventionally ignored by a preprocessor
(or at least, multiple blank lines treated as 1 line unless in quoted string).  
I know virtually nothing about troff/groff input requirements,
but it might be more generally 'user-friendly' to ignore blank lines
in source files by default and perhaps have a "strict" flag if blank
lines, "technically" shouldn't be there to issue the warnings.

A few other common messages ( just ran a pass over the basic
manX dirs on my system, only the common warnings:

     35 /usr/bin/eqn:: unquoted escape
     87 /usr/bin/zsoelim:: newline in .lf request, ignoring
     32 /usr/share/groff/1.17.2/tmac/eqnrc:: a node is not allowed in a name
     71 grotty:: character above first line discarded
    557 man:: whatis parse for xxx failed

(332 of the whatis parses are from the "Qt" man pages, another 52 are
from ppm man pages....)

        I don't know the severity of each error but some like "whatis
parse" failures should obviously be the responsibility of the man page
writer to fix.  Though if they are common "warnings" about things 
that really don't make a difference in the final output....maybe
those warnings could (should?) be suppressed unless explicitly enabled?
(--strict, --lint, etc...)

        My interest is only in trying too eliminate spurious warnings
about things that _usually_ don't have much importance for the 
average user... (which is different than the developer of a man page
who should have ran the damn thing through 12** versions of "man-lint"
before releasing it anyway! :-); **-random# )

Linda

named.conf.5.gz
Description: GNU Zip compressed data