[bug #59030] some warnings still emitted with

[Dave]

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

Summary: some warnings still emitted with
Project: GNU troff
Submitted by: barx
Submitted on: Fri 28 Aug 2020 03:48:39 AM CDT
Category: None
Severity: 3 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release: None

_______________________________________________________

Details:


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





_______________________________________________________

Reply to this item at:

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

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

[Dave]

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

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.

_______________________________________________________

Reply to this item at:

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

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

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

_______________________________________________________

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 #4, bug #59030 (project groff):


[comment #3 comment #3:]

Post by G. Branden Robinson
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.

_______________________________________________________

Reply to this item at:

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

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

[Dave]

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

[comment #2 comment #2:]

Post by G. Branden Robinson
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.

_______________________________________________________

Reply to this item at:

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

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

[Dave]

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

[comment #3 comment #3:]

Post by G. Branden Robinson
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:]

Post by G. Branden Robinson
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.

_______________________________________________________

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 #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

_______________________________________________________

Reply to this item at:

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

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

[Dave]

This post might be inappropriate. Click to display it.

[Ingo Schwarze]

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


_______________________________________________________

Reply to this item at:

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

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

[G. Branden Robinson]

Update of bug #59030 (project groff):

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


_______________________________________________________

Reply to this item at:

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

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

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

_______________________________________________________

Reply to this item at:

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

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