Tadziu Hoffmann wrote:
|> Why this? If i use \\*[DATE*SHORT] anything is fine, so it is
|> because the macro is evaluated while the string is defined.
|
|Yes.
|
|If you use the "string" like this:
|
| Some text before \*[DATE*SHORT], and some text after
|
|the expansion will yield
|
> Why this? If i use \\*[DATE*SHORT] anything is fine, so it is
> because the macro is evaluated while the string is defined.
Yes.
If you use the "string" like this:
Some text before \*[DATE*SHORT], and some text after
the expansion will yield
Some text before \c
.XX \\*[DATE*FULL]
,
Tadziu Hoffmann wrote:
|Just a short addendum:
|
|Since you know that you'll only be stripping off one of the
|known weekday names, there's also a simpler solution:
...
|However, there is still a caveat with these solutions: although
|\*[DATE*SHORT] may look like a (single-line) string exp
> But I don't think that eliminates the macro call stack
> growing on tail recursion, like dc(1) does for example?
True, groff does not have an optimization for tail recursion,
so the input stack will fill up even in this case.
> I see groff's info says «Note that the number of available
> recur
Just a short addendum:
Since you know that you'll only be stripping off one of the
known weekday names, there's also a simpler solution:
.\"
.de DATE*SHORT
\c
.XX \\*[DATE*FULL]
..
.de XX
.ds BB \\$*
.ds AA \\$1
.
Hi Tadziu,
> > > Or there's a `.while' IIRC. :-)
>
> The ".while" construct isn't strictly necessary, because the roff
> language supports recursion. 8-)
True! But I don't think that eliminates the macro call stack growing on
tail recursion, like dc(1) does for example? I see groff's info say
