Update of bug #54537 (project groff):
Item Group: None => Incorrect behaviour
_______________________________________________________
Follow-up 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.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?54537>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
