bugGNU roff - Bugs: bug #54537, [PATCH] om.tmac: Add block...

 
 

bug #54537: [PATCH] om.tmac: Add block brackets to avoid a warning about unbalanced .ie

Submitter:  Bjarni Ingi Gislason <bjarniig>
Submitted:  Sun 19 Aug 2018 04:29:03 PM UTC
   
 
Category:  Macro mom Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.22.4
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 22 Jan 2022 06:56:41 AM UTC, comment #7: 

This was an actual correctness issue with respect to *roff syntax, though whether it had any discernible impact on mom(7)'s operation, I am not remotely prepared to opine.

`el` is a request much like any other, and does not "bind" at a lexical level to its companion `ie` request more tightly than any other request does.  This means that if an `ie`/`el` pair is governed by another conditional, they must be braced for correct behavior.  Here's an illustration.


$ cat EXPERIMENTS/block-and-el.roff
.nr a 1
.nr z 0
.ie \nz \
.  ie \na a is true
.  el     a is false
.el z is false
$ ./build/test-groff -Tutf8 -b -ww EXPERIMENTS/block-and-el.roff | cat -s
troff: backtrace: file 'EXPERIMENTS/block-and-el.roff':6
troff:EXPERIMENTS/block-and-el.roff:6: warning: unbalanced 'el' request
a is false


Another trick you can play with `el` is (nowadays) documented in our Texinfo manual.


5.20.3 if-else
--------------

 -- Request: .ie cond-expr anything
 -- Request: .el anything
     Use the 'ie' and 'el' requests to write an if-then-else.  The first
     request is the "if" part and the latter is the "else" part.
     Unusually among programming languages, any number of
     non-conditional requests may be interposed between the 'ie' branch
     and the 'el' branch.

          .nr a 0
          .ie \na a is nonzero.
          .nr a +1
          .el a was not positive but is now \na.
              => a was not positive but is now 1.


G. Branden Robinson <gbranden>
Group administrator
Mon 19 Nov 2018 08:34:17 AM UTC, comment #6: 

Fixed in 5e392ea2a2ddfae0d5eb8c1c4d150d26c6a34241.

G. Branden Robinson <gbranden>
Group administrator
Mon 19 Nov 2018 07:31:54 AM UTC, comment #5: 

Going ahead with this since Peter approved the change, and has not pushed it himself.

G. Branden Robinson <gbranden>
Group administrator
Tue 06 Nov 2018 04:22:52 AM UTC, comment #4: 

Blocks are advantageous, no doubt, but at 23000+ lines, om.tmac benefits from the reduced clutter.  In the present instance, I agree the braces help.

With respect to patches to om.tmac, I prefer to inspect them myself before they're applied.  I develop mom actively, with fairly frequent releases.  Changes in the repo can mess up my commits.

When submitting proposed patches, make sure they're against the latest version of om.tmac. The om.tmac in a packaged groff, the one installed from a former build, and the official release in the repo are always out of sync, a side effect of developing mom separately from groff, so to speak.

Peter Schaffter <PTPi>
Group Member
Mon 05 Nov 2018 06:30:46 AM UTC, comment #3: 

Thanks, Bjarni.

I'm in general agreement with your principles, but unlike hdtbl, mom is actively maintained, and I'm a little hesitant to make this change without input from Peter Schaffter, especially if we don't understand why the warning can't be reproduced with the stock om.tmac.  That fact suggests a comprehension gap to me--one that Peter may be able to fill.

Peter, any ideas?

G. Branden Robinson <gbranden>
Group administrator
Sun 04 Nov 2018 09:32:20 PM UTC, comment #2: 

  I can't reproduce the warning with the "om.tmac" file
 ("test-groff -z om.tmac"), but with a shorter version:


.nr #TOC 1
.nr #LIST_OF_FIGURES 1
.nr #LIST_OF_TABLES 1
.nr #LIST_OF_EQUATIONS 1
.nr #DOC_LEAD 1
.nr #SAVED_DOC_LEAD 1
.
.    if \n[#SAVED_DOC_LEAD] \{\
.       if \
(\n[#TOC]=0)&\
(\n[#LIST_OF_FIGURES]=0)&\
(\n[#LIST_OF_TABLES]=0)&\
(\n[#LIST_OF_EQUATIONS]=0) \
.          ie !\n[#DOC_LEAD]=\n[#SAVED_DOC_LEAD] .nr #RERUN_TRAPS 1
.          el .nr #SKIP_TRAPS 1
.    \}

  "test-groff -z <file>" produces:

troff: prof.block:16: warning: unbalanced .el request


  I find using blocks a better practice, is more future proof, lines
(including comments) can be added, removed from the block, without
disturbing, destroying the skeleton, or adding block delimiters.

  Blocks also help the compiler, interpreter to process the code with
certainty (simpler rules).

  The eye reads physical lines, although the interpreter, compiler can
just get one single line to process.

Bjarni Ingi Gislason <bjarniig>
Sun 04 Nov 2018 05:49:36 PM UTC, comment #1: 

How did you provoke this warning?  Do you have a sample document?

G. Branden Robinson <gbranden>
Group administrator
Sun 19 Aug 2018 04:29:03 PM UTC, original submission:  


From c8e2fbba04a2cf4871108f07835ae403b71af327 Mon Sep 17 00:00:00 2001
From: Bjarni Ingi Gislason <bjarniig@rhi.hi.is>
Date: Sun, 19 Aug 2018 15:55:41 +0000
Subject: [PATCH] om.tmac: Add block brackets to avoid a warning about
 unbalanced .ie

Signed-off-by: Bjarni Ingi Gislason <bjarniig@rhi.hi.is>
---
 contrib/mom/om.tmac | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/contrib/mom/om.tmac b/contrib/mom/om.tmac
index 78bc13fb..bd0219d0 100644
--- a/contrib/mom/om.tmac
+++ b/contrib/mom/om.tmac
@@ -5879,9 +5879,10 @@ SMALLCAPS takes precedence.
 (\\n[#TOC]=0)&\
 (\\n[#LIST_OF_FIGURES]=0)&\
 (\\n[#LIST_OF_TABLES]=0)&\
-(\\n[#LIST_OF_EQUATIONS]=0) \
+(\\n[#LIST_OF_EQUATIONS]=0) \{\
 .          ie !\\n[#DOC_LEAD]=\\n[#SAVED_DOC_LEAD] .nr #RERUN_TRAPS 1
 .          el .nr #SKIP_TRAPS 1
+.       \}
 .    \}
 .    ie \\n[#ADJ_DOC_LEAD]=1 .
 .    el \
--
2.18.0


Bjarni Ingi Gislason <bjarniig>

 

(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 PTPi (Posted a comment)
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by bjarniig (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.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-01-22 gbranden Item GroupNone Incorrect behaviour
    2018-11-19 gbranden StatusIn Progress Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.22.4
    2018-11-19 gbranden StatusNeed Info In Progress
        Assigned toPTPi gbranden
    2018-11-05 gbranden Assigned toNone PTPi
    2018-11-04 gbranden StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code