[bug #59030] some warnings [errors] still emitted with -Ww

[G. Branden Robinson]

Update of bug #59030 (project groff):

Category: None => Core
Status: None => Need Info
Assigned to: None => gbranden
Summary: some warnings still emitted with => some warnings
[errors] still emitted with -Ww

_______________________________________________________

Follow-up Comment #2:

Well, that's 'cause it's an error, not a warning. ;-)

It even says so right there in the diagnostic message, though you'll find
that's a recent innovation; groff 1.22.4 and earlier didn't mention this.

The confusion seen here is exactly why I'm fairly militant about diagnostic
messages always including their diagnostic level.

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

Anyway, to suppress error messages, you have to use the -E option of groff or
troff.

_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?59030>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[G. Branden Robinson]

Follow-up Comment #3, bug #59030 (project groff):

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.

[G. Branden Robinson]

Follow-up Comment #4, bug #59030 (project groff):


[comment #3 comment #3:]

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

s/it doesn't/there isn't/

"Level" does indeed imply that there is, but that language is not used in
groff documentation. As I recall the state of the documentation and its
implications to the novice user, errors and warnings are simply different
things the program can yell about.

[Dave]

Follow-up Comment #5, bug #59030 (project groff):

[comment #2 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.

[Dave]

Follow-up Comment #6, bug #59030 (project groff):

[comment #3 comment #3:]

> Also, it appears that -E implies -Ww.
>
> I'm undecided as to whether it should.

Yeah, I can see arguments either way, though if it continues to work this way,
this should be documented.

[comment #4 comment #4:]

> errors and warnings are simply different things the program can yell about.

I do wonder whether this particular problem really rises to the level of
"error": it's nonfatal and about as severe as some other things deemed
warnings. For the very particular use case mentioned in comment #1, it would
be nice to be able to turn that message off with an appropriate .warn request,
and then turn it back on again after the attempt to set .g; there appears to
be no equivalent in-document mechanism for emulating -E.

But overall I'd say this is working as designed, so probably this report
should be closed.

[G. Branden Robinson]

Follow-up Comment #7, bug #59030 (project groff):

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

[Dave]

Follow-up Comment #8, bug #59030 (project groff):

I wouldn't necessarily advocate for a new category either. Having well-chosen
categories means that new situations that come up should be able to fit into
your existing category framework. Unfortunately, That's not necessarily the
path (g)roff has chosen: a warning category for "Use of a tab character where
a number was expected" is very oddly specific.

Nonetheless, the condition under discussion here could reasonably fit into one
of the existing categories.

* number: Invalid numeric expressions.
* range: Out of range arguments.
* syntax: Dubious syntax in numeric expressions.

While category names are part of the published command-line interface and
therefore can't be altered, their descriptions could be tweaked to be more
general.

[Ingo Schwarze]

Follow-up Comment #9, bug #59030 (project groff):

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.)

[G. Branden Robinson]

Update of bug #59030 (project groff):

Item Group: None => Documentation
Status: Need Info => In Progress

[G. Branden Robinson]

Update of bug #59030 (project groff):

Status: In Progress => Fixed
Open/Closed: Open => Closed
Planned Release: None => 1.22.5

_______________________________________________________

Follow-up Comment #10:

Fixed in b954f67228616a542af26729393c9156005fd3e1.