groff
[Top][All Lists]
Advanced

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

Re: eqn anomaly


From: G. Branden Robinson
Subject: Re: eqn anomaly
Date: Tue, 3 Mar 2020 13:37:00 +1100
User-agent: NeoMutt/20180716

At 2020-03-03T02:09:02+0100, Tadziu Hoffmann wrote:
> > As far as I can tell from Kernighan and Cherry[1], eqn's "define"s
> > aren't parameterized at all.  The groff eqn(1) man page claims to
> > document (only) extensions to classical eqn, but I don't see this
> > extension described there.
> 
> It actually does: in subsection "Macros":
> 
>    Macros
> 
>       Macros can take arguments.  In a macro body, $n where
>       n is between 1 and 9, is replaced by the nth argument
>       if the macro is called with arguments; if there are
>       fewer than n arguments, it is replaced by nothing.
>       A word containing a left parenthesis where the part
>       of the word before the left parenthesis  has  been
>       defined  using  the define command is recognized as a
>       macro call with arguments; characters following the
>       left parenthesis up to a matching right parenthesis
>       are treated as comma-separated arguments; commas inside
>       nested parentheses do not terminate an argument.

Yup, you're right; I read that part of eqn(1) in haste and concluded
wrongly that to get this behavior, you had to use "sdefine" or one of
the other keywords defined in that subsection.

> So it does mention grouping with parentheses being understood,
> but it says nothing about understanding "strings" delimited by
> quotes.

Yup.  With that in mind, GNU eqn produces the output I expect.

.EQ
define f % $1 %
f("a,b")
.EN
.
.EQ
"a
.EN

I get the same diagnostic twice.

Regards,
Branden

Attachment: signature.asc
Description: PGP signature


reply via email to

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