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. On Oct 28, 5:51 pm, Eric Shulman <[email protected]> wrote: > > 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en -~----------~----~----~----~------~----~------~--~---
