troff:ono.tmac:336: warning: name '$*' not defined [-w mac]

[g-branden-robinson]

$ nl ono.tmac | sed -n 332,342p
   332  .\" Clobbers:
   333  .\"     \*(*^B
   334  .de *
   335  .       br
   336  \h'-\\n(*~u-\\w,\\*(*%,u'\\*(*%\h'\\n(*~u'\*($*
   337  .       ds * \\g*
   338  .       af * 1
   339  .       nr * \\n*+1
   340  .       af * \\*(*
   341  .       rm *
   342  ..

Is this code doing what you intend? I see that a *% string is defined on line 312 (and potentially redefined in a "callback" on line 383), but nothing removes it, which suggests to me that that the * string can get interpolated before the package is prepared for it.

If this report is spurious, then you might do the .as * \" empty trick to silence the warning as in Issue #3.

[Alhadis]

Is this code doing what you intend? I see that a *% string is defined on line 312 (and potentially redefined in a "callback" on line 383)

Yeah, that's my attempt at allowing users to customise the marker string for a particular list level. By-and-large, any definition that doesn't use a C0 control character is intended and expecteed to be tampered with by authors (although now that C0 characters are haraam in Groff, I'll have to do away with that convention…)

As for \*($*, it's kind of supposed to be interpolated into the macro from this hacky attempt at a \$* wrapper that works with older Troffs. In other words, it's essentially embedding that giant mess into the macro for the sake of "conciseness".

Mono/ono.tmac

Lines 681 to 726 in 18a41b8

	.\" ===========================[ COMPATIBILITY ]============================{{{1
	.
	.\" Crude shims for $* and $@, used internally by Mono.
	.\" Doesn't support inline expansion; i.e., stuff like:
	.\"
	.\" .XY a \\*($* b
	.\"
	.\" Clobbers: \n($* \n($@
	.\" \*($* \*($@
	.\"
	.
	.nr $* 0
	.nr $@ 0
	.de $*
	. if !'\\$*'1 2 3' .nr $* 1
	. if !'\\$@'"1" "2" "3"' .nr $@ 1
	..
	.$* 1 2 3
	.ds $* \\\\$*
	.ds $@ \\\\$@
	.if \n($*=1 \{ .de $*
	\c
	\.ie \\\\n(.$=1 \\\\$1\c
	\.el .ie \\\\n(.$=2 \\\\$1 \\\\$2\c
	\.el .ie \\\\n(.$=3 \\\\$1 \\\\$2 \\\\$3\c
	\.el .ie \\\\n(.$=4 \\\\$1 \\\\$2 \\\\$3 \\\\$4\c
	\.el .ie \\\\n(.$=5 \\\\$1 \\\\$2 \\\\$3 \\\\$4 \\\\$5\c
	\.el .ie \\\\n(.$=6 \\\\$1 \\\\$2 \\\\$3 \\\\$4 \\\\$5 \\\\$6\c
	\.el .ie \\\\n(.$=7 \\\\$1 \\\\$2 \\\\$3 \\\\$4 \\\\$5 \\\\$6 \\\\$7\c
	\.el .ie \\\\n(.$=8 \\\\$1 \\\\$2 \\\\$3 \\\\$4 \\\\$5 \\\\$6 \\\\$7 \\\\$8\c
	\.el .if \\\\n(.$>8 \\\\$1 \\\\$2 \\\\$3 \\\\$4 \\\\$5 \\\\$6 \\\\$7 \\\\$8 \\\\$9\c
	.. \}
	.if \n($@=1 \{ .de $@
	\c
	\.ie \\\\n(.$=1 \&"\\\\$1"\c
	\.el .ie \\\\n(.$=2 \&"\\\\$1" "\\\\$2"\c
	\.el .ie \\\\n(.$=3 \&"\\\\$1" "\\\\$2" "\\\\$3"\c
	\.el .ie \\\\n(.$=4 \&"\\\\$1" "\\\\$2" "\\\\$3" "\\\\$4"\c
	\.el .ie \\\\n(.$=5 \&"\\\\$1" "\\\\$2" "\\\\$3" "\\\\$4" "\\\\$5"\c
	\.el .ie \\\\n(.$=6 \&"\\\\$1" "\\\\$2" "\\\\$3" "\\\\$4" "\\\\$5" "\\\\$6"\c
	\.el .ie \\\\n(.$=7 \&"\\\\$1" "\\\\$2" "\\\\$3" "\\\\$4" "\\\\$5" "\\\\$6" "\\\\$7"\c
	\.el .ie \\\\n(.$=8 \&"\\\\$1" "\\\\$2" "\\\\$3" "\\\\$4" "\\\\$5" "\\\\$6" "\\\\$7" "\\\\$8"\c
	\.el .if \\\\n(.$>8 \&"\\\\$1" "\\\\$2" "\\\\$3" "\\\\$4" "\\\\$5" "\\\\$6" "\\\\$7" "\\\\$8" "\\\\$9"\c
	.. \}
	.rr $*
	.rr $@

But I actually hate the hack and wish I had a better way of interpolating every available macro argument in a manner that older Troffs will understand.

[g-branden-robinson]

But I actually hate the hack and wish I had a better way of interpolating every available macro argument in a manner that older Troffs will understand.

I don't know of a way other than the one you're using, and given experiences with DWB 3.3, I am fearful that there is some fixed maximum "stack" size allocated for macro arguments that combines with the syntactical limitation of interpreting only the first nine.

n-t-roff/DWB3.3#10

[Alhadis]

I am fearful that there is some fixed maximum "stack" size allocated for macro arguments that combines with the syntactical limitation of interpreting only the first nine.

I recall writing a macro that treated the following lines as arguments to a macro, which worked by ending a line in a custom escape character that was only set when the macro is executed (thus preventing lines ending in \ from being folded into a single line when the macro's body is being read).

I don't know what became of it, but I vaguely recall Groff complaining about "using a node in a string context" or something. Basically, the lines' contents weren't being picked up as ordinary string data. This hack worked on Heirloom Doctools, though.

[g-branden-robinson]

I am fearful that there is some fixed maximum "stack" size allocated for macro arguments that combines with the syntactical limitation of interpreting only the first nine.

I recall writing a macro that treated the following lines as arguments to a macro, which worked by ending a line in a custom escape character that was only set when the macro is executed (thus preventing lines ending in \ from being folded into a single line when the macro's body is being read).

I don't know what became of it, but I vaguely recall Groff complaining about "using a node in a string context" or something. Basically, the lines' contents weren't being picked up as ordinary string data. This hack worked on Heirloom Doctools, though.

If you ever recover or recreate it, I'd be curious to see how groff 1.24.x handles it. The befuddling and mysterious "node"-related diagnostic messages are an area I've done some recasting and cleanup in (and with respect to the operation of the asciify request--which can operate on nodes--a wholesale overhaul). For 1.24 I also updated the GNU troff internals section of our Texinfo manual to throw more light on these matters.