[bug #45502] [troff] .if, .ie, .el parsing incompatible with Unix V7, DWB, and Heirloom Doctools troff

Follow-up Comment #7, bug #45502 (group groff): [comment #6 comment #6:] >If an `el` request or the >conditional expression of an `if` or `ie` request is followed >immediately by a newline, then (A) if in AT&T compatibility >mode, ignore the newline character as AT&T troff did Thi

[bug #45502] [troff] .if, .ie, .el parsing incompatible with Unix V7, DWB, and Heirloom Doctools troff

Follow-up Comment #8, bug #45502 (group groff): [comment #6 comment #6:] > GNU troff treats a newline and EOF equivalently in this case. Also I don't get how that's possible. GNU troff treats a newline at the end of an .if condition as an implied join with the following line. If EOF instead o

[bug #45502] [troff] .if, .ie, .el parsing incompatible with Unix V7, DWB, and Heirloom Doctools troff

Follow-up Comment #9, bug #45502 (group groff): [comment #8 comment #8:] > [comment #6 comment #6:] > > GNU troff treats a newline and EOF equivalently in this case. > > Also I don't get how that's possible. GNU troff treats a newline at the end of an .if condition as an implied join with the

[bug #45502] [troff] .if, .ie, .el parsing incompatible with Unix V7, DWB, and Heirloom Doctools troff

Follow-up Comment #10, bug #45502 (group groff): [comment #9 comment #9:] > That was a stale comment. I had included checks `|| tok.is_eof()` while developing this, but backed them out. Will fix. (If I don't end up putting the checks back in light of comment #8.) I meant comment #7. ___

[bug #45502] [troff] .if, .ie, .el parsing incompatible with Unix V7, DWB, and Heirloom Doctools troff

Follow-up Comment #11, bug #45502 (group groff): [comment #7 comment #7:] > [comment #6 comment #6:] > >If an `el` request or the > >conditional expression of an `if` or `ie` request is followed > >immediately by a newline, then (A) if in AT&T compatibility > >mode, ignore the newl

[bug #45502] [troff] .if, .ie, .el parsing incompatible with Unix V7, DWB, and Heirloom Doctools troff

Follow-up Comment #12, bug #45502 (group groff): Wow, it's actually GNU _troff_ that aggressively reads through the newline. I wasn't expecting that. $ cat EXPERIMENTS/truncated-if4.roff .if 0 A .if !0 B .ie 0 C .el D .pl \n(nlu $ ~/groff-stable/bin/nroff EXPERIMENTS/truncated-if4.roff B D $

[bug #45502] [troff] .if, .ie, .el parsing incompatible with Unix V7, DWB, and Heirloom Doctools troff

Follow-up Comment #13, bug #45502 (group groff): I have a better exhibit. $ cat EXPERIMENTS/truncated-if4.roff .nm 1 @ .if 0 A .if !0 B .ie 0 C .el D E .pl \n(nlu $ cd ~/heirloom/ $ ./bin/nroff truncated-if4.roff 1 @ A 2 B C 3 D E $ cd ~/dwb $ DWBHOME=. ./bin/nroff truncated-if4.roff

[bug #45502] [troff] .if, .ie, .el parsing incompatible with Unix V7, DWB, and Heirloom Doctools troff

Follow-up Comment #14, bug #45502 (group groff): That last version of the exhibit is now the basis of the regression test, which passes (along with our other 202 tests) with this simple patch. I discarded most of what is shown in comment #6. diff --git a/src/roff/troff/input.cpp b/src/roff/trof

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

Update of bug #65474 (group groff): Severity: 2 - Minor => 3 - Normal Status: Confirmed => Duplicate Assigned to:None => gbranden Open/Closed:

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

Follow-up Comment #1, bug #65549 (group groff): Resolving this _might_ also eliminate the need to say `\%` again after `\:` escape sequences. ___ Reply to this item at: ___

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

Update of bug #65474 (group groff): Status: Duplicate => None Open/Closed: Closed => Open ___ Follow-up Comment #13: Nope, I'm sorry, the o

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

Follow-up Comment #14, bug #65474 (group groff): The example shows a bug in groff or an interpretation as in some other language. That interpretation is not mentioned in "https://troff.org/54.pdf"; (Troff User's Manual, Nov 1992; chapter 16). The 'ie' request has nothing to process on the

[bug #60260] [troff] formatter matches `el` requests with `ie` differently than Unix V7, DWB, and Heirloom

Update of bug #60260 (group groff): Status: Confirmed => None ___ Follow-up Comment #5: My comment #4 is _not_ illustrative of a _groff_/AT&T compatibility issue. What it illustrates is A

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

Follow-up Comment #15, bug #65474 (group groff): [comment #14 comment #14:] > The example shows a bug in groff or an interpretation as in some > other language. This comment is not helpful when you don't specify _which example you're talking about_. There are several in this ticket's traffic.

[bug #45502] [troff] .if, .ie, .el parsing incompatible with Unix V7, DWB, and Heirloom Doctools troff

Follow-up Comment #15, bug #45502 (group groff): [comment #12 comment #12:] > Wow, it's actually GNU _troff_ that aggressively reads through > the newline. That _was_ Carsten's original complaint. [comment #14 comment #14:] > That last version of the exhibit is now the basis of the > regression

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

Follow-up Comment #16, bug #65474 (group groff): [comment #11 comment #11:] > Could you explain why Tadziu's argument is cogent? I'm not > following it. In a nutshell, groff short-circuits in a quirky and nonintuitive way. In this code: .ie condition1 action1 .el .ie condition2 action2 .el acti

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

Follow-up Comment #17, bug #65474 (group groff): My posting (comment #14) was an answer to comment #11 (Paul Eggert). The example, with a possible explanation .pl 3 .de MY .ie '\\$1'a' CASE a .el .ie '\\$1'b' CASE b .el CASE z .. .ie '1'1' \{\ . ie '1'2' .el .MY a\" groff pr

[bug #45502] [troff] .if, .ie, .el parsing incompatible with Unix V7, DWB, and Heirloom Doctools troff

Follow-up Comment #16, bug #45502 (group groff): [comment #15 comment #15:] > [comment #12 comment #12:] > > Wow, it's actually GNU _troff_ that aggressively reads through > > the newline. > > That _was_ Carsten's original complaint. Sometimes I don't evaluate the truth value of a proposition un

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

Update of bug #65474 (group groff): Status:None => In Progress ___ Follow-up Comment #18: I propose to fix this by killing the warning category along with the spuriousness. commit ab22aa4