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 newline character as AT&T troff did
>
> This description doesn't seem to match AT&T behavior. "Ignore the newline
character" implies, to me, that AT&T troff processed
>
> .if 1
> .tm true
>
> as if it were written
>
> .if 1 .tm true
>
> But in fact AT&T troff processes it as if it were
>
> .if 1 .do-nothing
> .tm true
>
> So AT&T troff is in essence ignoring the .if request...which is what's
written next in the commit message, for NON-compatibility mode:
>
> > (B) otherwise, emit a warning in
> > category `el` and ignore the _request_.
>
> Are these descriptions backwards, or is my understanding?
I'm not sure. I don't think this is baked yet. I need to check two more
things.
1. What happens if these conditionals have false predicates? I'm only doing
that in one place ("startlingly"), but it's not startling if the request turns
into a no-op. And if *that's* the case then I may not need to do things
different for compatibility mode after all, but just fix an ancient _groff_
bug.
2. Is a newline _immediately_ after the conditional really ignored by AT&T
_troff_, or does it put a break on the output same as any other newline? If
the latter, does that depend on whether the predicate is true?
So, no, I don't have it. Not yet. But I'm on the scent.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?45502>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
