bugGNU troff - Bugs: bug #59030, some warnings [errors] still...

 
 

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

Submitted by:  Dave <barx>
Submitted on:  Fri 28 Aug 2020 08:48:39 AM UTC  
 
Category:  Core Severity:  3 - Normal
Item Group:  Documentation Status:  Fixed
Privacy:  Public Assigned to:  G. Branden Robinson <gbranden>
Open/Closed:  Closed Planned Release:  1.23.0

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Wed 02 Sep 2020 01:42:54 PM UTC, comment #10: 

Fixed in b954f67228616a542af26729393c9156005fd3e1.

G. Branden Robinson <gbranden>
Project AdministratorIn charge of this item.
Sat 29 Aug 2020 11:32:11 PM UTC, comment #9: 

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

Ingo Schwarze <schwarze>
Project Member
Fri 28 Aug 2020 10:45:03 PM UTC, comment #8: 

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.

Dave <barx>
Project Member
Fri 28 Aug 2020 11:19:22 AM UTC, comment #7: 

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

G. Branden Robinson <gbranden>
Project AdministratorIn charge of this item.
Fri 28 Aug 2020 10:09:24 AM UTC, comment #6: 

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:

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

Dave <barx>
Project Member
Fri 28 Aug 2020 09:47:12 AM UTC, comment #5: 

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 <barx>
Project Member
Fri 28 Aug 2020 09:18:24 AM UTC, comment #4: 

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.

G. Branden Robinson <gbranden>
Project AdministratorIn charge of this item.
Fri 28 Aug 2020 09:15:01 AM UTC, comment #3: 

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 <gbranden>
Project AdministratorIn charge of this item.
Fri 28 Aug 2020 09:08:12 AM UTC, 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.

G. Branden Robinson <gbranden>
Project AdministratorIn charge of this item.
Fri 28 Aug 2020 09:02:09 AM UTC, comment #1: 

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.

Dave <barx>
Project Member
Fri 28 Aug 2020 08:48:39 AM UTC, original submission:  

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

Dave <barx>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by schwarze (Posted a comment)
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-09-02 gbranden StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
        Planned ReleaseNone => 1.23.0
    2020-09-01 gbranden Item GroupNone => Documentation
        StatusNeed Info => In Progress
    2020-08-28 gbranden CategoryNone => Core
        StatusNone => Need Info
        Assigned toNone => gbranden
        Summarysome warnings still emitted with => some warnings [errors] still emitted with -Ww

    Back to the top


    Powered by Savane 3.6