Does <<__...__>> make $...$ obsolete in macro definitions?

[S. S.]

Should every macro definition only use     <<__...__>>    instead of   $...$   for text substitution ?

If so, should every macro definition be updated?

At the moment I am asking with specific reference to the definitions of Documentation Macros I am updating which can be seen here: $:/editions/tw5.com/doc-macros

[Mark S.]

Not as far as I'm concerned .I don't think you can use <<__...__>> for classic substitution.

Try this at tiddlywiki.com:

\define test(link) [[$link$]]
\define test2(link) [[<<__link__>>]]

<<test HelloThere>><br/>
<<test2 HelloThere>>

The one with $link$ works. The one with <<__link__>> doesn't.

-- Mark

[Mohammad]

Hi S.S,

 Have a look at: https://kookma.github.io/TW-Scripts/#Shorthand%20Syntax%20Summary

and follow the discusion by Eric Shulman.

--Mohammad

[TonyM]

S S and Mohammad,

On the subject of this thread, Each have their place  <<__...__>>  Vs $...$ 

• All $ wrapped items are substitutions and very helpful for concatenation or constructing strings from "Parameters"
  
• <<__...__>> allows parameters to be passed directly into a widget or a macros wikiText as if it were a variable when suitable to do so
  It reduces the need to convert parameters into variables with vars or set widgets.

In my view we do not need <<__...__>> but it is very useful

I have a draft tiddler published that addresses these issues comprehensively which I intend to maintain. 

It helps address the issues raised in this thread. Feedback requested. I hope to provide a feedback mechanism in the future 

Variables, Parameters and Transclusions

Regards

Tony

[S. S.]

Here was my problem while trying to fix the <<.tag>> macro in $:/editions/tw5.com/doc-macros

\define .tag0(_) $_$
\define .tag1(_) <$text text=$_$/>
\define .tag2(_) <$text text=<<_____>>/>


<<.tag0  $:/tags/Stylesheet>>
<<.tag1  $:/tags/Stylesheet>>
<<.tag2  $:/tags/Stylesheet>>

.tag0 (the original) works fine normally, but for CamelCase, it displays the parameter as a CamelCase link - which was not what is wanted:  $:/tags/Stylesheet
.tag1 works fine normally, but for CamelCase it completely breaks down and shows: <$text text=$:/tags/Stylesheet/>
.tag2 works perfectly, and I want to understand why.

So I can see that  <<__...__>> works well as the parameter of a widget, in this case the $text widget.
Some simple examples of other places it is useful would help clear the fog!

Thanks.

P.S. Is it normal behaviour for this TEXT to show up as a link whether CamelCase is turned on or off? : $:/tags/Stylesheet
 

[Mark S.]

Change .tag1 to :

\define .tag1(_) <$text text="""$_$"""/>

and it works too.

Yes, unless you use <$text>, change the settings, or some other technique, camelcase is going to happen.

Good luck!

-- Mark

[TonyM]

I will just add $_$ and where applicable $(_)$ are substitutions, so you can use delimiters such as "$_$" to delimit them, which is necessary for System tiddler titles, perhaps because : or / gets treated as delimiters.

Thus <$text text=$:/tags/Stylesheet/> Fails

<$text text="$:/tags/Stylesheet/"/> will work

so <$text text="$_$"/> will work

Using <<__parametername__>> looks like a variable, and contains its own delimiters the angle brackets.

Using "<<__parametername__>>" would turn it into a literal string that is not evaluated to the value of parametername

Regards

Tony

[S. S.]

Thanks Mark!

I wonder why it works. Strange, as there are no quotation marks in : $:/tags/Stylesheet
Is it because $:/tags/Stylesheet gets wikified regardless of whether a TW has CamelCase set On or OFF?
And why does any text starting $:/anyletter become a link? I don't believe that behaviour is documented.

As for the solution to the issue - would you know which is the more robust solution?

\define .tag1(_) <$text text="""$_$"""/>

or

[TonyM]

I Updated this and are in the process of building a comprehensive and hopefully usable table.

[S. S.]

Well, noticing that a system tiddler name is auto turned into a link led to some better understanding of the SYSLINK parsing rule!
There is no documentation about it - yet.

Control Panel > Info > Advanced > Parsing

With syslink enabled, any system tiddler name gets turned into a link! It is on by default.

One method is to switch it off in the Control Panel. I wonder what would break if this was done.
Another is to use \rules except syslink at the top of a tiddler.
A third, interestingly, is the same as switching off CamelCase, which is to use :  ~$:/tags/Stylesheet

So now, back to which is the more robust solution?

[TonyM]

S s

I think its a matter of opinion. I choose the first because I know it will handle single and double quotes, even if the second does as well and you do confuse the name with the syntax in the second.

Regards
Tony

[Mark S.]

I think, technically, that #2 is the official answer. But you'll have to search the forum to find Jeremy's explanation of what problems the new <<__...__>> variables solved. I think it had to do with the possibility of tiddler titles containing quote marks.

Solution #1 is more versatile, easier to understand, easier to write, and can concatenate text, so I tend to use it by default. But if I was writing something to be used by thousands of people, I might take a longer look at #2.

-- Mark

[Jeremy Ruston]

Hi Mark

That’s correct: we expose macro parameters as variables so that it is possible to safely refer to parameters that may contain quotation marks. 

Otherwise, a construction like <div attr="$param$"> fails if the parameter contains a double quote. In the core we use triple double quotes which only fails when the parameter string ends with a double quotation mark.

The new double underscore syntax to referr to parameters as variables doesn’t obviate the need for the usual $-delimited format. It can still make sense to use the $-delimited format when you really do want text substitution to take place. (Having said that, those concatenations can also be achieved via filter operators).

As a general rule of thumb, if the output of a macro is intended to be wikified then it is usually appropriate to refer to parameters as variables. If the output of the macro is not intended to be wikified (eg constructing a tiddler title from several parts) then its usually best to use text subsitution.

If I was approaching this now I wouldn’t provide support for text substitution in macros (and thus wouldn’t need the double underscores when referring to parameters as variables). Although it looks enticingly simple, as we see from the discussions here it is full of pitfalls for the unwary.

Best wishes

Jeremy

-- 
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/20c091f7-7395-47cf-9112-f575782daeb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark S.]

Hi Jeremy,

Thanks for the explanation -- I'm bookmarking it this time!

-- Mark