bugGNU roff - Bugs: bug #59434, doc/groff.texi: document .if / .ie...

 
 

bug #59434: doc/groff.texi: document .if / .ie interaction more clearly

Submitter:  Dave <barx>
Submitted:  Mon 09 Nov 2020 12:00:57 PM UTC
   
 
Category:  Core Severity:  1 - Wish
Item Group:  Documentation Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 07 Apr 2024 08:17:48 AM UTC, comment #5: 

comment #4:

> I guess we should get our terminology straight.
>
> For the infamous original submission sample code, if COND1 is false, groff emits the .el warning.  Do you consider this warning spurious?


Yes.

Since at the time the document is composed, we can't know the truth value of COND1 (otherwise we wouldn't bother to write a conditional predicated on it in the first place), we must assume that its true branch can be taken.  Therefore the `ie` is interpreted and a counterpart `el` is expected.
 

> Based on everything written on this so far, I'm inclined to say no: in the COND1=false case, groff does not see the .ie request, so when it hits the .el, that .el is, in fact, unmatched; ergo, the warning is of an actual condition (i.e., not a false positive); ergo, not spurious.
>
> Have we diverged in our ideas of spuriousness, or are we together so far?


You have put your finger on where we disagree.

As a rule, I think syntax validation operations should be able to rely upon the syntax of the input remaining valid even within branches that are not taken.

Under your interpretation, I think, it is permissible to have a syntactically invalid register definition inside an untaken branch.


.if 0 .ie \nA .nr a\&b 1
.      el     .nr c\&d 2


I think that we must reject this notion, else someone will not only attempt the foregoing, but change the `\&`s to `\{` and `\}` and insist that we cope.

G. Branden Robinson <gbranden>
Group administrator
Sun 07 Apr 2024 07:41:01 AM UTC, comment #4: 

I guess we should get our terminology straight.

For the infamous original submission sample code, if COND1 is false, groff emits the .el warning.  Do you consider this warning spurious?

Based on everything written on this so far, I'm inclined to say no: in the COND1=false case, groff does not see the .ie request, so when it hits the .el, that .el is, in fact, unmatched; ergo, the warning is of an actual condition (i.e., not a false positive); ergo, not spurious.

Have we diverged in our ideas of spuriousness, or are we together so far?

Dave <barx>
Group Member
Sun 07 Apr 2024 06:34:34 AM UTC, comment #3: 

original submission:

> Consensus on the email list (thread starting at http://lists.gnu.org/archive/html/groff/2020-09/msg00000.html)


I'm afraid I have to depart from this consensus, given recent study in this area; see bug #45502 and bug #65474.

> is that
>


> .if COND1 .ie COND2 xxx
> .          el yyy


>
> is not a legal construction (or rather, is only legal when COND1 is true).


I claim that it's valid regardless of the truth value of COND1, and all *roff formatters we've studied reliably produce the same results given it (for my part, that's Unix V7, Solaris 10, DWB 3.3, and groff from 1.22.3 to the present day).
 

>  But the documentation does not make this clear, saying the part after the condition in an .if request "is interpreted as though it were on a line by itself."  Were the .ie in fact on a line by itself, groff wouldn't emit an "unbalanced .el request" warning when COND1 is false.


That's a problem with the warning diagnostic being an insufficiently powerful interpreter of roff input when skipping over a branch not taken.  It doesn't "see" that `ie`, even in the absence of an immediately following `\{`, creates a new "level" of conditional with which coupling of a subsequent `el` request is expected.
 

> Further down the email thread, Branden writes a lengthy analysis why .if "hides" an .ie but processes \{ and \}.  While informative, hopefully there is a more succinct way to explain this in the groff documentation.


And indeed I've tried to explain it several more times in the ticket traffic of the last few days.

If I hit upon a presentation that you find persuasive, I'll likely weight that heavily when considering what language to add to our Texinfo manual to deobfuscate this matter.

Though I hope that just shutting up the spurious "unbalanced 'el'" warnings will do considerable work toward that goal.


G. Branden Robinson <gbranden>
Group administrator
Thu 25 Mar 2021 05:02:37 AM UTC, comment #2: 

See also bug #60260

Dave <barx>
Group Member
Wed 25 Nov 2020 06:57:24 PM UTC, comment #1: 

  This code is invalid (the term "legal" in this connection is
inappropriate, see "GNU standards" and the (real) translations
of the term in "*.po" files).

  The scope of ".if" is here two lines not one.

  This example is a demonstration of what happens when people transfer
(bad programming) practice from one language to another.

  So, with a "multi line" input ... [see "Troff User's Manual", CSTR #54;
chapter 16].

Bjarni Ingi Gislason <bjarniig>
Mon 09 Nov 2020 12:00:57 PM UTC, original submission:  

Consensus on the email list (thread starting at http://lists.gnu.org/archive/html/groff/2020-09/msg00000.html) is that


.if COND1 .ie COND2 xxx
.          el yyy


is not a legal construction (or rather, is only legal when COND1 is true).  But the documentation does not make this clear, saying the part after the condition in an .if request "is interpreted as though it were on a line by itself."  Were the .ie in fact on a line by itself, groff wouldn't emit an "unbalanced .el request" warning when COND1 is false.

Further down the email thread, Branden writes a lengthy analysis why .if "hides" an .ie but processes \{ and \}.  While informative, hopefully there is a more succinct way to explain this in the groff documentation.

Dave <barx>
Group 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 gbranden (Posted a comment)
  • -email is unavailable- added by bjarniig (Posted a comment)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code