[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
signature.asc
Description: PGP signature