Hi,
> 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.
Returning to Doug's aim, does avoiding using a literal comma suffice?
$ cat eqn.tr
.EQ
define f % $1 %
f("a\N'44'b")
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.
>
>
> 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
Ma
At 2020-03-01T23:07:07-0500, Doug McIlroy wrote:
> .EQ
> define f % $1 %
> f("a,b")
> .EN
>
> draws a diagnostic from Gnu eqn: "newline before end of quoted text".
> Remove the comma and all is well. Apparently the comma delimits
> the first argument.
>
> The program isn't totally naive about par
.EQ
define f % $1 %
f("a,b")
.EN
draws a diagnostic from Gnu eqn: "newline before end of quoted text".
Remove the comma and all is well. Apparently the comma delimits
the first argument.
The program isn't totally naive about parsing arguments. It
does think that there's only one argument in the m
