[bug #65474] spurious "warning: unbalanced 'el' request" when formatting zic(8) from TZDB project

[Dave]

Follow-up Comment #5, bug #65474 (group groff):

I agree with Paul that -ww is not intended as a style check.  But I further
contend that this is not subpar style.

[comment #3 comment #3:]
>   The translator is not happy about how the instructions are
> written, they are not informative enough for an unambiguous
> processing.

There is nothing ambiguous about the code in Paul's original example, either
to a human reader who understands basic if/then/else syntax, or to a machine
parser (theoretically, and seemingly in practice, except that something is
confusing groff's parser into emitting a spurious warning).  Braces are not
required for this construction in C.

#include 
main() {
  if (1 == 2)
puts("Weird");
  else if (2 < 1)
puts("Also weird");
  else puts("Normal");
}

When "if" statements are nested without braces, there can be ambiguity about
which one an "else" applies to.  But there is none here.


___

Reply to this item at:

  

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

[bug #65474] spurious "warning: unbalanced 'el' request" when formatting zic(8) from TZDB project

[Paul Eggert]

Follow-up Comment #4, bug #65474 (group groff):

[comment #3 comment #3:]
>   one can look at "groff" as being a (minimal) "code
> and style checker".
That's not the intent of groff -ww. The intent is to catch errors, not report
style issues. The groff documentation says that -ww should issue this
diagnostic only when "The 'el' request was encountered with no prior
corresponding 'ie' request." In the TZDB man page there is a prior
corresponding 'ie' request, therefore groff should not warn.

Although it might be helpful for groff to have a style checker, that should be
a separate option, and it should not be enabled by default.


___

Reply to this item at:

  

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

[bug #65549] [troff] automatic hyphenation suppressed with leading `\%` roars back to life after break

[G. Branden Robinson]

Update of bug #65549 (group groff):

 Summary: [troff] hyphenation suppressed with `\%` roars back
to life after break => [troff] automatic hyphenation suppressed with leading
`\%` roars back to life after break


___

Reply to this item at:

  

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

[bug #65549] [troff] hyphenation suppressed with `\%` roars back to life after break

[G. Branden Robinson]

URL:
  

 Summary: [troff] hyphenation suppressed with `\%` roars back
to life after break
   Group: GNU roff
   Submitter: gbranden
   Submitted: Tue 02 Apr 2024 06:32:52 PM UTC
Category: Core
Severity: 3 - Normal
  Item Group: Incorrect behaviour
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Tue 02 Apr 2024 06:32:52 PM UTC By: G. Branden Robinson 

$ printf '.ll 8n\n\\%%antidisestablishmen\\%%tarianism\n' | nroff -Wbreak |
cat -s
antidisestablishmen‐
tarian‐
ism



Hyphenation should stay off **until the end of the word** except where infixed
`\%` escape sequences occur.







___

Reply to this item at:

  

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