TiddlyWiki 5.2.0 Release discussion

[TW_Tones]

Hi folks,

Now TiddlyWiki 5.2.0 Release discussion

I just wanted to open a discussion on the still to come TiddlyWiki 5.2.0 because it has some substantial changes and improvements, that may take some time for the community to “make use of”. You can experiment with it get the prerelease here (you can even right click this link and download a local copy).

It is provided for testing purposes. Please don’t try to use it for anything important – you should use the latest official release from https://tiddlywiki.com.

The development team will be keen to see any bugs if you discover them, perhaps discuss or raise an issue over here however I want to start the discussion with all users .

There are in particular some enhancement that are going to allow us to find whole new ways we achieve things, as a result I expect quite a few annoyances in the past will be eliminated. Here are a few that I see as having an impact in our use of wikitext, macros and widgets.

This is from my own biased perspective.

• Unrestricted Fieldnames
  • Lots of possibilities here with field names being able to contain spaces, whole tiddler titles prefixed and suffixed in any way you want.
• More Flexible Parsing of Macros
  • It will now be possible to nest macro calls within the parameters to other macros <<mymacro arg:"""nested <<macro>> call""">>
  • Pass macro parameters in Filters
    [<now [UTC]YYYY0MM0DD0hh0mm0ssXXX>]
• It will now be possible to use an EditWidget to edit another field of the same tiddler. Previously, the edit widget would not work properly in such cases because it would be refreshed on every keypress, leading to the current editing caret/selection position being lost.
• ListWidget with optional counter attribute specifying a variable to contain the numeric index of each list item.
• There are improvements to the events and actions that I expect may have substantial impact on ways we can add features to the User Interface and add additional actions, however I do not yet understand this enough to make use of it.
• Various filter operators and improvements including
• more statistics
• formatting titles using the [[title with spaces]] rules
• easily accessing special characters like tab and linefeed ‘Charcode operator’
• ## RefreshThrottling may help when generating large complex tiddlers to improve performance.
• text operation insert-text which can improve the smarts of new Editor Toolbar buttons. And easy ways to create new Editor Toolbar buttons to complement this.

[TW_Tones]

@TW_Tones

More Flexible Parsing of Macros

• It will now be possible to nest macro calls within the parameters to other macros <<mymacro arg:"""nested <<macro>> call""">>
• and Pass macro parameters in Filters
  [<now [UTC]YYYY0MM0DD0hh0mm0ssXXX>]

I am yet to test and understand exactly what will result with this, but I am looking forward to it.

I think this will be an area where whole new code patterns can be developed and old ones abandoned.

• So often work arounds were necessary or additional code needed in additional macros just to make something happen in the first place, now they will be able to happen right where they are needed.
• Variables and macros can easily be set with any content from lists, to transclusions and other macros and now you can feed these directly into another macro or even a filter to treat the content differently.
  • you could write macros that write filters that can be easily given as a parameter.
• Now when using core or your own macros you may not need to revert to the macrocall widget so often, just to get a dynamic parameter passed into the macro.
• The short macro form (not macrocall widget) allows you to pass parameters according to their position rather than a specific name, so being able to pass macros to macros will open some serious new possibilities.

[sobjornstad]

@TW_Tones

It will now be possible to nest macro calls within the parameters to other macros <<mymacro arg:"""nested <<macro>> call""">>

Ooh, I was just running into some weird glitch with this yesterday and didn’t realize this was the source of the problem for fifteen minutes or so. Too bad I wasn’t working on that a couple weeks from now!

Now I’m just waiting for a way to force these to evaluate immediately so we can use them as HTML attributes:

<$text text=<<mymacro <<mynestedcall>>>>/>
<$text text=<<mymacro {{!!transclusion}}>>/>

[TW_Tones]

With my tests you must delimit the inner macros and nothing I saw yet suggests the transclusion will work as a parameter.

<<M1 "<<m2 Parm>>">> should work

For pasers by you can use the macrocall widget to call any macro with almost any parameter.

I can see that since macros can do a lot this new method is easier to read. Where as before I could pass a filter as a parameter now we can also pass macros that are evaluated for you as a parameter to your macro rather than your macro do the work. This was always possible with macrocall but the shorter form has the advantage of ordered parameters rather than named parameters.

[sobjornstad]

@TW_Tones

With my tests you must delimit the inner macros

Right, what I wrote was an “I wish we could do this with something like this syntax.”

@TW_Tones

nothing I saw yet suggests the transclusion will work as a parameter.

It works exactly the same way as the macro does, try it.

I think both of us misunderstood what this change meant initially. What changed in the prerelease is that the >> in the innor macro doesn’t make the parser freak out. It doesn’t allow the dynamic parameter to be evaluated before calling the macro like $macrocall does.

So these are equivalent:

<<mymacro "<<inner macro call>>">>
<$macrocall $name=mymacro param="<<inner macro call>>"/>

These aren’t equivalent, as I had initially assumed, thus my wishful-thinking suggested syntax:

<<mymacro "<<inner macro call>>">>
<$macrocall $name=mymacro param=<<inner macro call>>/>

In either case, this only does what you want if the parameter to mymacro gets wikified. But there is not now, nor was there ever, any problem accomplishing this with a field transclusion as the quoted argument to the macro.

Here’s an example which you can try on prerelease if any of that isn’t clear:

<!-- parameter is wikified -->
\define ok(param) $param$
<!-- parameter is not wikified -->
\define bad(param) <$text text="$param$"/>
\define inner() TEST

<<ok "<<inner>>">>
<<ok "{{!!title}}">>

<<bad "<<inner>>">>
<<bad "{{!!title}}">>

This prints:

TEST
New Tiddler
<<inner>>
{{!!title}}

[pmario]

Macros are text substitution only. They never return wikified values.

[sobjornstad]

@pmario

Macros are text substitution only. They never return wikified values.

@pmario, I’m not sure what you’re responding to. If you meant the comments in my example, I may have phrased it in a confusing way…in the example, the parameter does eventually get wikified when the ok macro is called, since the parameter ends up directly in the text field, whereas it never does when the bad macro is called, since it ends up as an attribute.

[Charlie_Veniot]

@sobjornstad

@pmario, I’m not sure what you’re responding to

Completely off-topic, but I figure the best place to mention because it is happening right here in this discussion thread.

One of the many things that are cognitively challenging for me regarding TiddlyTalk: I often have no idea who is replying to what mini-thread of discussion within the greater discussion.

So I get easily confused, and I wind up escaping that discussion as quick as I can at the cost of missing out on some good stuff.

Please, I don’t mean to start a discussion about that in this thread. Any further discussion (which I probably won’t participate in) best in a dedicated thread of discussion.

[TW_Tones]

Charlie,

In support of what you are asking we need to encourage the community to do what you did like quoting

Because of the features so activated (see arrow).

The down arrow results in this;

Also if we use the reply at the bottom of the thread

You are basically replying to the original post, or the thread in general.

If someone is responding to a specific post, as I am to yours ,we must use the reply on the actual reply we are responding to;

[TW_Tones]

Mario,

This fact has being restated many times by you, Eric and Jeremy but rarely are the consequences explained.

They never return wikified values.

Only goes part of the way, because this is not what appears to be happening to us.

I will try and make my own Quote, please help me improve it.

Macros are text substitution only.
They never return wikified values until the final render of the tiddler that generate the HTML that we see in the result.

• The Wikify widget allows you to bring forward this “rendering step” if the result is important to the logic.

[pmario]

@sobjornstad

@pmario, I’m not sure what you’re responding to.

Sorry, it should have been:

@sobjornstad

<!-- parameter is wikified -->
\define ok(param) $param$

The comment here is a bit misleading. The parameter $param$ is “replaced” when the macro is called. So the action when the macro os called is like a “search / replace” here.

[pmario]

@sobjornstad

\define bad(param) <$text text="$param$"/>

should be: \define bad(param) <$text text=$param$/> … See the missing quotes around $param$

Then it works for parameters like <<inner>> and {{!!title}}

BUT it will break with "text with spaces". …

That’s has nothing to do with wikification, but is a weakness, how the parser works.

---

While the mechanism itself is straight forward. It’s not easy to explain, how the whole “wikification” mechanism works, because it’s hard to see the different steps, that are involved.

I need to think about it.

[TW_Tones]

I am starting to think this is not much of an advantage.

The parameter $param$ is “replaced”

And we have historically called it “substituted” or “Substitution” as is the case for $(varname)$

On a related note I have in the past crafted macros of this form

<<macroname fieldname>>
<<macroname varname>>

And then we can get[$fieldname$] or getvariable[$varname$] name them in the define.

Despite the “improvement’s” ie
<<macroname "<<innermacro>>" >>

the only extra value is to reuse existing macros and use the parameters
<<macroname "<<innermacro inner parameters>>">> in the initial call.
We can already do the following; <<macroname innermacro>> then ;

\define macroname(macro)
<$macrocall $name="$macro$" ...../>
\end

[twMat]

Feel free to skip this post - I just need a place to vent:

AW GUUUUYS! So much good coming up in this release! Nested macros - what??? That was totally unexpected. And EditText in current tiddler - I had come to accept the “not possible” as a law of nature! Unrestricted fieldnames, DnD images, … on and on!
You guys!!!

[CodaCoder]

Frankly, honestly, I’ve been more than a little apprehensive about the upgrade to 5.2.0…

I just upgraded one of my wikis – the wiki I spend most of my day using. It contains more tiddlers and (what gave me pause to be apprehensive) more hacks than the staff canteen at The Sun newspaper.

In terms of testing, it’s early days, obviously (heck, early minutes!) but OMG… it’s working fine.

HUGE CONGRATS to the people that made this groundbreaking release and upgrade possible.

Did I try any of the new stuff (in anger) yet? Apart from the new store, no… but this first run gives me full encouragement to try stuff (if I’m not paralyzed by the sheer amount of new things to try!)

[clutterstack]

I’ve been using the prerelease in all my messing-about wikis, and nothing has broken. I can’t even keep up with the rate of increase in power and flexibility of TiddlyWiki. I’m already committed to the range operator and :map prefix going forward.

Great stuff! Many thanks to all contributors!