allows to use macro references in macro parameters

[tobibeer]

Using the following syntax this change allows to pass macro syntax
within macro parameters as follows...

<<tiddler Template with: '<<tag Foo>+>'>>

All '>+>' are be replaced with '>>' BEFORE further processing.

In fact, this will work for any macro, e.g.

<<foo "<<bar>+>" >>

[pmario]

hmmm
Wouldn't it be better to "fix" the core macro parser

... what if I want to do:

<<tiddler one with: "<<tiddler two with: '<<tag foo >+>' >+>" >>

[tobibeer]

How? My regexp skills certainly are not at this level of debate. Anybody willing and able to translate this into plain language...

lookaheadRegExp: /<<([^>\s]+)(?:\s*)((?:[^>]|(?:>(?!>)))*)>>/mg,

?

Being able to directly do any of...

<<foo "<<bar>>">>

<<foo '<<bar>>'>>

<<foo [[<<bar>>]]>>

or even...

<<foo [[<<bar '<<baz>>' >>]]>>

...would definitely be better. Although, knowing that a pragmatic '>+>' works, too, doesn't feel like it's hurting all that much.

Theoretically, you could even do...

<<foo [[<<bar '<<baz>++>' >+>]]>>

..and also replacing >++> with >+> to be handled the next turn.

Surely, things like these might add up to a number of (perhaps) undesireable quirks. But perhaps they really don't? It definitely seems more intuitive than some <<popup>>-macro style $)).

[pmario]

@Jermolene ... did you try to let the macro formatter digest

<<tiddler one with: "<<tiddler two with: '<<tag foo >>' >>" >>

[Jermolene]

The macro parser in TW classic isn't sophisticated. It assumes that the
first ">>" marks the end of the macro. There's no straightforward way to
fix this; regexps alone isn't sufficient to parse the examples that Tobias
gave.

Best wishes

jeremy

On Tue, Oct 15, 2013 at 9:46 PM, Mario Pietsch [email protected]:

@Jermolene https://github.com/Jermolene ... did you try to let the
macro formatter digest

<<tiddler one with: "<<tiddler two with: '<>' >>" >>

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/151#issuecomment-26370704
.

Jeremy Ruston
mailto:[email protected]
http://www.tiddlywiki.com

[pmario]

@tobibeer there is a syntax that can handle your usecase.

<<tiddler "asdf##test" with: {{"<<tag foo>"+">"}}>>

/%
! test
$1
!%/

The only problem is, that for tiddlyspace you'll need to set: config.evaluateMacroParameters = "full";

So probably your pull request would be a better solution ??

[tobibeer]

Hi Mario, I think there are more problems with that than taking the 'hacking TiddlySpace' barrier... the evaluated parameter syntax simply is mostly too complicated for your everyday user and I think, rightfully so. Using macros and transclusions can be simpler and I think my example definitely is. The question for me is, need I wrap this in a plugin or 'core-hack', or will it actually improve things as a core feature. I don't think the overhead is all that dramatic, even with the code allowing a sequential replacing of...

>+++>
>++> 
>+> 
>>

Tobias.

[pmario]

@ericshulman ... what do you think?

[tobibeer]

Another pro for this solution is that (with a few bits of additional code) it can support this...

<<foo [[<<bar '<<baz>++>' >+>]]>>

Current evalled parameters cannot, afaict. I know, it's somewhat exotic... but perhaps it actually isn't all that much.

[YakovL]

Hello guys,
Note1: there's another issue though about macro params handling. There's generally no escaping for the param wrappers.. I mean, if I wrap a param into double-quots, I can't use double-quots inside it etc. From time to time, this causes some problems, too. So maybe we should think of some more general solution here..

Note2: the >> always finish the macro syntax (changing this seems to be complicate wikifying anyway), but the formatter can "look forward" (like the formatter of the gradient macro does).

Idea: we can extend the macro syntax with an "escaping zone", which will work like this:

<<macroName "ordinary" [[params]] 'with' different {{"wrappers"}}>>>escaping zone>>

And escaping zone will be added to the paramString param of the handler, but before, \', \", \>, \[, \] and \\ will be substituted with their "literal" analogues. So, the <<foo "<<bar>>" >> thing should be written as

<<foo>>>"<<bar>\>">>

The tripple > is here instead of double to reduce the wikification time: most macros won't have escaping zone, and looking forward shouldn't take much time if a macro haven't an EZ.

Note3: alternative delimeters for EZ can be used. For the particular case of <<foo "<<bar>>" >>, one can imagine some other delimeters that will allow not to escape the > and > symbols, like
<<foo>>%"<<bar>>"% or <<foo>>/%"<<bar>>"%/
and also parsing can be done so that in this particular case the double-quots wrapper shouldn't be used:

<<foo>>%<<bar>>%

Note4: when determining EZ after >>>, more complicated parsing can be used. For instance, it can count >> and << symbol sequences and allow to skip escaping:

<<foo>>>"<<bar>>">>

as EZ ends when the number of appeared >> is one more than that of <<.