Follow-up Comment #19, bug #65474 (group groff):
[comment #18 comment #18:]
> I propose to fix this by killing the warning category along with
> the spuriousness.
With two longtime groff users (Tadziu and Bjarni, with me still on the fence)
arguing that the warning isn't spurious, I wonder if thi
Follow-up Comment #20, bug #65474 (group groff):
I confess that I still don't know how .ie and .el work, despite the attempts
in the documentation (and in this bug report) to explain them. For example,
given the following test of nesting .ie and .el two deep (in .MX) and three
deep (in .MY):
.pl
Follow-up Comment #21, bug #65474 (group groff):
[comment #20 comment #20:]
> I can't explain why .MX's two levels of .ie/.el work, whereas .MY's three
levels do not work; can anyone else explain it?
Never mind, I now see the missing "\}" after the ".el D" line. Sorry about the
noise in my previo
Follow-up Comment #22, bug #65474 (group groff):
[comment #19 comment #19:]
> [comment #18 comment #18:]
> > I propose to fix this by killing the warning category along with
> > the spuriousness.
>
> With two longtime groff users (Tadziu and Bjarni, with me still on the
fence) arguing that the wa
Update of bug #60260 (group groff):
Status:None => Invalid
Open/Closed:Open => Closed
___
Follow-up Comment #6:
Let us port the specime
Follow-up Comment #23, bug #65474 (group groff):
[comment #11 comment #11:]
> Solaris 10 /usr/bin/nroff outputs "CASE a", which is what I'd expect.
Heirloom troff does as well.
> gnroff outputs "NOTREACHED", which is surprising.
My guess at the end of comment #16 was wrong. This, it turns out,
Follow-up Comment #24, bug #65474 (group groff):
[comment #23 comment #23:]
> [comment #11 comment #11:]
> > Solaris 10 /usr/bin/nroff outputs "CASE a", which is what I'd expect.
>
> Heirloom troff does as well.
>
> > gnroff outputs "NOTREACHED", which is surprising.
>
> My guess at the end of
Follow-up Comment #25, bug #65474 (group groff):
[comment #22 comment #22:]
> Sure, but I'd like to do that once the 3 of us (you, me, and
> Paul) are on the same page, so that we aren't arguing any
> facts, just the advisability of future action.
👍
> Yours and Bjarni's claims in that ticket are
Follow-up Comment #26, bug #65474 (group groff):
[comment #24 comment #24:]
> I think my recast[1] of the relevant material in our Texinfo
> manual is a reliable guide to interpretation.
It's a reliable guide to other-troff interpretation. But in groff, change
that example's ".nr force-word-brea
Follow-up Comment #27, bug #65474 (group groff):
[comment #25 comment #25:]
> [comment #22 comment #22:]
> > Sure, but I'd like to do that once the 3 of us (you, me, and
> > Paul) are on the same page, so that we aren't arguing any
> > facts, just the advisability of future action.
> I guess it's
Update of bug #60260 (group groff):
Item Group: Incorrect behaviour => Warning/Suspicious
behaviour
Status: Invalid => Duplicate
___
Follow-up Comment #7:
[comment #6 commen
Update of bug #60260 (group groff):
Summary: [troff] formatter matches `el` requests with `ie`
differently than Unix V7, DWB, and Heirloom => [troff] spurious warning about
unbalanced "el" request
___
Follow-up Comment #8:
Follow-up Comment #17, bug #45502 (group groff):
[comment #16 comment #16:]
> Sometimes I don't evaluate the truth value of a proposition
> until I've inspected the machine that interprets it. 😅
"Trust, but verify," as they say (though the second step seems to render the
first moot).
> You are
Update of bug #42675 (group groff):
Summary: \} considered as macro argument regarding register
.$ => \} considered as macro argument
___
Follow-up Comment #7:
More wisdom from the email threads cited in comment #1 and com
Follow-up Comment #3, bug #59434 (group groff):
[comment #0 original submission:]
> Consensus on the email list (thread starting at
http://lists.gnu.org/archive/html/groff/2020-09/msg0.html)
I'm afraid I have to depart from this consensus, given recent study in this
area; see bug #45502 and
15 matches
Mail list logo
