gbranden wrote:

> I'm fairly militant about diagnostic messages always including their diagnostic level.

I like that, and i think it makes a lot of sense in multiple levels.

> I'm undecided as to whether it should.

I think it is very good that -E implies -Ww.  By definition, errors are more severe than warnings, so if the user doesn't even worry about errors, it is eminently logical that they worry about warnings even less.  In the unusual situation that somebody isn't interested in errors but wants to see particular warning, they can say something like -E -w break.  So there is no missing functionality and no surprising behaviour, unless i misunderstand.

> I'm sure there is some resistance to adding another warning category

Yes, i for example would appreciate keeping the number of categories small, there are too many already for my taste.  I doubt that many users actually used them.  Some certainly use -w all and/or -w w but i guess very few bother configuring categories individually.  It is generally better to group messages by severity (e.g. error, warning, style issue) than by topic.  Easier to use - more likely to actually get used, and used productively.

> I'm inclined to leave this open for the time being as just
> a documentation bug.

I would consider saying "-E implies -W w" (if that is indeed true) at the appropriate place or places reasonable, unless it is already said there.

(As an aside, i agree that the warning categories are not just too many but also somewhat ill-designed, but that isn't easy to fix, and even if one were willing to break compat, overhauling a message system tends to require a lot of work, and then there is still a risk that the new system might end up just different and not much  better.)

I'm inclined to leave this open for the time being as just a documentation bug.

But I'd like to hear from other groff folks to see what they think.

I'm sure there is some resistance to adding another warning category, since they're encoded as bitmasks exposed in the language.  Before long we'll stop being portable to 32-bit platforms... :P

comment #2:

> I am kind of chagrined that my efforts failed here, though.

Your efforts didn't fail; my reading failed.

More specifically, I encountered this on an earlier release that lacked the word "error," overlooked that word on initial copy/paste from the latest groff, and probably would have noticed it while proofing the report before submitting it, but savannah took that choice away from me (which irked me enough to open http://savannah.nongnu.org/support/index.php?110299 against savannah).  There's a decent chance that by the time I'd investigated more fully, I'd have decided against opening the bug report at all.  Takeaway: write all bug-tracker drafts in another window, not in savannah itself.

Also, it appears that -E implies -Ww.

I'm undecided as to whether it should.

It makes sense if there is an ordering over diagnostic levels, and not if it doesn't.

Apparently hitting an accidental "return" with the cursor in the summary field tells savannah "Submit this now!" no matter how few fields are populated.

The summary was to have read, "some warnings still emitted with all warnings turned off".

The body was to have read:

$ echo .nr .g 4 | groff -Ww
troff: <standard input>:1: error: can't write read-only register

-Ww is supposed to silence all warnings, but doesn't.

Why would this one need to be silenced, you wonder?  Isn't trying to assign to a read-only register something the user should just correct?

As it turns out, using the .g register to distinguish GNU groff from Heirloom troff is not as straightforward as it should be, because Heirloom has a "groff compatibility mode" that sets .g to 1.  What is different between them, however, is that Heirloom lets you assign to .g, whereas groff (as the example above shows) does not.  So this is a reliable test to see which troff you're running; however, it generates an unsilenceable warning in groff.