bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #60672] troff: No warning about ".el \{"


From: G. Branden Robinson
Subject: [bug #60672] troff: No warning about ".el \{"
Date: Wed, 26 May 2021 02:03:37 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Follow-up Comment #3, bug #60672 (project groff):

Quoting verbatim stuff angered Savannah.  Let's try that again.

Hi Bjarni,

Thanks for the report, but I'm afraid it's invalid.

[comment #0 original submission:]
> Subject: troff: No warning about ".el \{"
> 
>   Example:
> printf '.pl 20v
> .nr i 1
> .if i=1 \{
> .  nop
> .\}
> .ie i=0 \{
> . nop
> .\}
> .el \{
> . nop
> .\}' | test-groff -z

The above is valid input.  The \{ escape begins a scope for the preceding .if,
.el, .ie, or .while request, and the very first thing it does in its scope is
put a newline on the input stream.

_Usually_, that's not what people really want, so we encourage the
'\{\newline' syntax as an idiom.

But, occasionally, it might be desired.

My new man(7) blank line macro just tracked down such a case in gpinyin(1). 
But the line numbers were way off because I had a tbl(1) table inside an .ie,
and thus tbl(1) was powerless to restore them.  That's something I should add
to the tbl(1) man page, I reckon.

> troff: backtrace: file '<standard input>':3
> troff: <standard input>:3: warning: missing closing delimiter in
> conditional expression (got newline)
> troff: backtrace: file '<standard input>':6
> troff: <standard input>:6: warning: missing closing delimiter in
> conditional expression (got newline)

You got these diagnostics because you have apparently misunderstood how to
perform an arithmetic comparison in *roff.  You cannot compare a bare register
name to anything--you have to _interpolate_ it first.

Instead of


.if i=1 i equals one


try


.if \ni=1 i equals one


and I think you'll be happier.  What is happening is that GNU troff(1) is
interpreting 'i' as the opening delimiter of a "string" comparison (really, a
formatted output comparison) operation.  (Heirloom Doctools troff does the
same, but issues no diagnostics.)

In Heirloom, you _do_ have to wrap the arithmetic comparison in parentheses,
even if it has no internal whitespace.


.if (\ni=1) .tm i really does equal one


But as noted above, this is not necessary in groff.  I would recommend the
parentheses as good style nevertheless.

> N.B.
> 
>   .if ... \{
> 
> did not work in an HP operation system.

Without seeing more, like what was in the "...", I cannot advise whether HP's
implementation was normative per CSTR #54.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60672>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]