macros invoked twice, e.g. tiddler-macro

[Tobias - http://tbGTD.tiddlyspot.com]

Hi everyone,

I am looking for a solution/method to get around this behaviour where
macros are executed twice. Searching trac I sadly find this issue to
be a wontfix http://dev.tiddlywiki.org/ticket/1035

Is there anyone here who knows how to fix it? I personally would love
to see this annoying behaviour to be a thing of the past, even if that
means that I have to mod every single defective plugin myself.

Plugins are not set in stone, if the platform (tiddlywiki) moves on,
because at some point it didn't quite go down the right road, so must
its applications (plugins & other bits of code) or they will fall
behind.

The tiddler macro turns out to do a great job at transclusions! And
that is why I think this idempotency issue is restricting its
usability way too much, like 'you better not wikify'...

Tobias.

[Martin Budden]

The problem is that a large number of macros rely on the current
behaviour, and that a fix would break these macros.

The correct fix would be to remove the call to readMacroParams() in
invokeMacro() and then have any macros parse their parameters
themselves. But as I said, this will break a large number of plugins.

Martin

2009/10/25 Tobias - http://tbGTD.tiddlyspot.com <beert...@googlemail.com>:

[Eric Shulman]

> The problem is that a large number of macros rely on the current
> behaviour, and that a fix would break these macros.

> The correct fix would be to remove the call to readMacroParams() in
> invokeMacro() and then have any macros parse their parameters
> themselves. But as I said, this will break a large number of plugins.

I have extensively studied this issue, and have a robust, simple
solution that works:

1) In invokeMacro(), change this line of code

m.handler(place,macro,
params.readMacroParams(),
wikifier,params,tiddler);

to

m.handler(place,macro,
!m.noPreParse?params.readMacroParams():[],
wikifier,params,tiddler);


Then, for any macro that does it's own invocation of parseParams() or
readMacroParams(), simply set the .noPreParse flag... e.g.:

config.macros.tiddler.noPreParse=true;

If the flag is not defined (or is set to false), the *current* macro
param processing behavior will be performed. Only when the flag is
set to TRUE will any change in behavior occur. Thus, this change is
100% backward-compatible with all existing macros, and also allows
remediation of existing core and plugin-defined macros, simply by
adding one line to each macro definition, and/or by adding a single
block of code during startup that adds the flag to all the desired
macros... i.e.,:

var names=['macroname','macroname','macroname',...];
for (var i=0;i<names.length;i++)
config.macros[names[i]].noPreParse=true;

The current behavior for parsing 'eval params' is *extremely*
problematic: because of the multiple evals, any code within the param
that is not idempotent will produce incorrect, and potentially
corrupted, results.

For example, suppose a macro handler that directly invokes parseParams
() expects a 'next available index' param (perhaps to generate a new,
auto-numbered tiddler). Let's also assume that the current value is
stored in some global tracking variable (e.g.,
config.options.txtNextIndex).

When the following macro code is invoked:
<<myMacro {{config.options.txtNextIndex++}}>>
the current index is retrieved and the global variable is
incremented. But, because of the 'multi-parse' problem, the macro
handler re-parses the param and increments it *again*, producing
incorrect results from the macro.

Similarly, it is also very problematic to invoke functions in eval
params that produce user-visible output, such as:
<<tiddler {{alert('This message is shown TWICE')}}>>
or
<<tiddler {{wikify('rendered TWICE',place)}}>>

Please, let's fix this ASAP.

your thoughts?

-e

[Tobias - http://tbGTD.tiddlyspot.com]

Hi Eric and Martin,

I really like your fix, Eric! I think it would make the core code much
more robust and reliable for future development... and thus I hope to
see something like this being integrated into it. In the meantime I
guess it is up to myself and others to use the fix you described.
Therefore, have you already gotten around:
* writing a "CoreTweak" on the issue?
* generating a list of core macros (or even widely used plugins) that
benefit from such a fix... to be included in some startup script/
array?

Much appreciated!


Tobias.

[Martin Budden]

Eric,

I like your patch as well. We'll put it into the 2.6 release.

Martin

2009/10/29 Tobias - http://tbGTD.tiddlyspot.com <beert...@googlemail.com>: