[snip] > I assume this comes from the fact that the macro expands the > argument twice - i.e., passes it on to yet another macro.
Yes, probably. (See the attached experiment.) > It's not only weird that sometimes arguments have to be quoted > once, sometimes twice and even more often - it also results in > the problem that macro does not work transparently and > changing the implementation might require to re-implement > calls of it. The plausible explanation is that the macro is simply buggy: if it is clear that arguments with spaces are to be expected, and the macro passes its arguments on to another macro, it should have quoted them. > I find it strange that one requires knowledge about the "inner > workings" of a specific macro in order to know how to quote > arguments to it. If you're trying to work around a buggy macro then I see no other way than being familiar with its inner workings to be able to find a successful workaround. > Is what I said in [1] true and there is in fact no consistent > method and rather, quotes cannot be escaped like one would do > in C? If the macro were properly written, then as a user you would simply quote the argument, and everything works as expected. You shouldn't need to escape quotes as you escape backslashes to delay their interpretation.
.\" .\" Tested with groff -Tps .\" ---------------------------------------------------------------- .de 1 \m[red]internally unquoted:\m[] .br .2 \\$1 .br \m[red]internally quoted:\m[] .br .2 "\\$1" .sp .. .de 2 \\$1 .. .\" ---------------------------------------------------------------- .sp 10v .ll 9m .nr ht 28v \D'l 0 \n[ht]u'\h'\n[.l]u'\v'-\n[ht]u'\D'l 0 \n[ht]u' .nh .1 Long argument with spaces .1 "Long argument with spaces" .1 Long\ argument\ with\ spaces .tr ~ .1 Long~argument~with~spaces .1 """Long argument with spaces
