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

[Dave]

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

Upon further digging, this appears to be a duplicate of bug #60260.  Jim
opened that bug report in 2021, but it's a restatement of an issue he
previously brought up in 2013:
http://lists.gnu.org/r/bug-groff/2013-02/msg3.html


___

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

[Bjarni Ingi Gislason]

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

  I sent my contribution to the groff list for more people to
read, with title

"An exercise for the brain(-software) (bug #65474)".



___

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

[Bjarni Ingi Gislason]

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

  What I forgot to write:

Another language has polluted the code, as written.



___

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

[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 #65474] spurious "warning: unbalanced 'el' request" when formatting zic(8) from TZDB project

[Bjarni Ingi Gislason]

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

  This is neither a spurious nor a "false positive" but a
legitimate remark about the code.

  I don't see a balance (like a two arm weight balance) with 
separate left and right loads.

  The warning is falsely interpreted (translated) by humans.

  The translator is not happy about how the instructions are
written, they are not informative enough for an unambiguous
processing.

  The writer's duty is to supply the translator with all
necessary information to make its work efficient, correct and
without any doubt.

  When humans look at the code, they add (get, have) information
that the translator does not have.

.ie \n(.g groff
.el .ie t troff
.el neither groff nor troff

  So simply adding the needed information for a unique
interpretation is

.ie \n(.g groff
.el \{ .ie t troff
.el neither groff nor troff \}

  which is not visible enough and not an enough structured style,
changing to 

.ie \n(.g groff
.el \{\
.  ie t troff
.  el neither groff nor troff
.\}

makes the "balance" visible at first glance.

  In this case one can look at "groff" as being a (minimal) "code
and style checker".

  The false interpretation (translation) of warnings by humans is
thus more common than one might suspect.

  Changing the code in "groff" to eliminate such a warning is
simply censorship and sabotage.

N.B.

  The showed warning "el" (code = 16) should be elevated to
a default status.



___

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

[G. Branden Robinson]

Update of bug #65474 (group groff):

Category:None => Core   
Severity:  3 - Normal => 2 - Minor  
  Item Group:None => Warning/Suspicious
behaviour
  Status:None => Confirmed  
 Summary: false positive "warning: unbalanced 'el' request"
when processing TZDB zic.8 => spurious "warning: unbalanced 'el' request" when
formatting zic(8) from TZDB project

___

Follow-up Comment #2:

Can reproduce.

I reduced Paul's exhibit further.


$ cat EXPERIMENTS/eggert2.roff 
.ie \nA .tm register A is truthy
.el .ie t .tm in typesetter mode
.el .tm in terminal mode


In terms of the `tm` terminal messages above, I get equivalent results on all
of _groff_ 1.22.3, 1.22.4, 1.23.0, and git HEAD; Heirloom Doctools _troff_ and
_nroff_; DWB 3.3 _troff_ and _nroff_; and Seventh Edition Unix _troff_ and
_nroff_.

I'll share output only the last since it's the most interesting in an
archeological sense.


Restricted rights: Use, duplication, or disclosure
is subject to restrictions stated in your contract with
Western Electric Company, Inc.
Thu Sep 22 22:07:57 EDT 1988

login: dmr
$ cat > eggert2.roff
.ie \nA .tm register A is truthy
.el .ie t .tm in typesetter mode
.el .tm in terminal mode
$ nroff eggert2.roff
in terminal mode
$ nroff -rA1 eggert2.roff
register A is truthy
$ troff -t -rA1 eggert2.roff
@o`register A is truthy
`~@I$

$ troff -t eggert2.roff
@o`in typesetter mode
`~@I$
sync
$ 
login: 
Simulation stopped, PC: 002306 (MOV (SP)+,16)


The same spurious diagnostic is emitted in all cases with all tested versions
of _groff_, though the correct branch is also taken in all cases.

Setting to "Minor" severity because it is only an annoyance and does no
violence to formatting.

Still, would be nice to fix because spurious diagnostics reduce confidence in
others.


___

Reply to this item at:

  

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