Tadziu Hoffmann <[email protected]> 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 | | Some text before \c | .XX \\*[DATE*FULL] | , and some text after | |and this in turn will eventually expand to | | Some text before \c | December 31, 2038<no_newline> | , and some text after | |giving as the total effect | | Some text before \c | December 31, 2038, and some text after | |which is completely okay in running text. | |When using it as | | .ds LH Formatted on \*[DATE*SHORT] | |it will yield | | .ds LH Formatted on \c | December 31, 2038 | |which simply stores "\c" in the string LH, and writes the |date into the running text instead.
Ok. Thanks, yes i am very rusty, it has been a long time since i looked into the macro side.. |> Is this restriction documented somewhere? If not |> it is a bug to keep on the TODO list, thank you! | |It's not a bug, it's a reminder not to use tricks that confuse |strings and macros, even if they are treated internally very |similarly during expansion. It seems to me it would be nice to have some kind of "auto-div" that is active as long as a .ds creation is in progress, so that this is kept together.? What do you mean? A nice rest weekend from my side, Ciao --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
