Thats to be seen, here I want us to learn it, support it and/or criticism of it.
This and other options were considered and debated.
To me this is so fundimental it should be core behaviour.
An initial look into the new format is it will be a good complement to list and reveal which are currently our main conditional content tools.
But I do feel the same about leveraging the existing contructs.
Plus :cascade, it could be argued.
Please check your second “function” code example in the OP. It does not work.
I think it’s very confusing to overload the tilde ~ sign with a user defined variable, since tilde is already used in filters for :else filter run.
I fixed the filter, just had the wrong name. A copy paste error.
Would you object to [*[]... it also look like current.
IMO the TW core is a good example that single-character shortcuts are problematic over the long run. We do run out of usable meaningful characters, that are available on different language specific keyboard layouts.
IMO if you really need a shortcut for currentTiddler then use cT. – But also here, the experience shows, that verbosity has an advantage.
I think that’s the best argument for verbosity.
From my point of view we should let ~ and _alone for variable names, if we want to establish best practices. Tilde and underscore are not good enough
No
Was that a bad question of mine?, You dont object?, I will assume you do object 
Sorry English is not my main language and consulting leo.org did give me the wrong impression.
I think verbosity wins in the long run, even if it is more to type.
Don’t be, I used a troublesome “turn of phrase”.
They are also wrong in official docs. I’ll create a PR to fix them.
Just some pointers to more context. There has been a lot of discussions about the new syntax here and at GitHub.
An if-then-else wikitext syntax has often been requested by standard users, since they consider nested $reveal and $list constructions unintuitive and complex.
The problem with <$list></$list> <$else></$else> format are discussed in details at GitHub. Starting with an initial PR, which was incompatible with Evan Blaster’s “condition” plugin. So it was rejected. Evan Blasters “condition” plugin is brittle, that’s why if-then-else was implemented in the way as it is now.
The merged implementation ist at: https://github.com/Jermolene/TiddlyWiki5/pull/7710
There is also a long thread about the proposed syntax from end of August 2023 here at Talk
Based on what? Your opinion? That is not reflected at all in my experience.
I suspect part of the issue may be that the $else widget will fail if separated from the closing tag of its antecedent by, say, an extra line break. I don’t mind this too much myself, especially because it does inform me when it fails (as opposed to most core widgets, which often just fail silently if their syntax is incorrect, and perhaps break something else further down the page.) But I suppose it could create some “unexpected” errors, since core widgets are generally fairly apathetic to whitespace.
Which, IMV, is not “brittle”, in practice or otherwise.
True. Perhaps text node walking/traversing was difficult back when <$if>/<$else> was introduced. But Evan does make it crystal clear in his docs.
Hi @Flibbles,
As an intermediate user, I do enjoy crossing thresholds of “getting it” about how TW “wants” me to approach things. I’ve absorbed the habit of using a <$list> widget — often with limit[1] in its filter — to accomplish display of conditional elements, and later I may refactor once I see the power of a template or cascade approach. It’s kinda cool, in an occam’s razor way. Like learning how to build out a whole circuit board with NAND gates. 
Still, nearly every newbie here at the forum has a bit of a struggle with why <$list> counts as the right tool for the task they come here to ask about — given that what they want seems (to them) nothing like a “list”!
Meanwhile, the cascade mechanism is a tremendously powerful way of handling conditional matters, but it’s unwieldy for most ordinary tasks.
(Erring on the side of keeping certain complexities “in-tiddler” is understandably tempting for ordinary users who want most tiddler names to be nodes of meaning directly relevant to their project, and who want their “Recents” tab to track that recognizable project content, not little utility tiddlers that do work behind the scenes.)
I think the new <% if %> affordances (even if <% elseif %> feels a bit roundabout) hits a sweetspot of intelligibility (as well as preserving backward compatibility).
After all, displaying something conditionally is the kind of task that pretty much any beginner will need to do, and even for me, I suspect this new shortcut tool will make my future self less confused (and/or will free up time otherwise lost to writing out comments to my future self about what’s going on with each nested level of <$list> here).
Since the <% if %> toolset offers a cognitive shortcut, it’s optional whether to use it, right?
There’s often a tradeoff between encouraging “optimal” habits and letting people rely on gaurdrails, training wheels, etc. I think it’s reasonable for most US-market keyboard manufacturers to put qwerty labels on the keys, even though you really shouldn’t look at your hands while you type — and even though nobody should be using Qwerty anyway. 
) At the risk of supporting bad habits for those who never get it about touch-typing (let alone what makes a keyboard layout a choiceworthy one), it’s still mighty helpful to those who haven’t yet streamlined their skills, and who might have more urgent projects at hand.
My God, @Springer, post of the week (if not year). Exemplary.
And your cross-disciplinary analogies → NAND gates. Boole and De Morgan would be proud!
Thanks @Flibbles, and apologies for my delayed response. Your comments are valuable feedback, and I’m delighted to receive them before it’s too late for this release.
I am happy to delay the release for a week to allow for further discussion if enough people think that it is warranted. It would be useful to hear from others who have concerns about this new syntax.
An assumption within the core is that widgets are independent of their siblings. There is no lateral flow of variable values or anything else. I do recognise this as a limitation of the current design. A particular motivation to update the design would be to be able to compute running heading numbers in wikitext.
I know that Evan’s conditional plugin does work laterally in the widget tree, but I think it is brittle, and constrains what we can do with the widget tree.
I disagree. The core has many instances of the list widget being used for if-then-else logic, and they will all be much clearer once we’ve updated the templates to use the new syntax.
That is correct.
The problem that the new syntax attempts to solve is readability and brevity.
Eloquently put. It is certainly true that conditional logic is needed much less frequently in TiddlyWiki than in some other environments, but it is still very common.
I can’t agree with the characterisation of if-then-else as an anti-pattern because I think it is common and (with the new syntax) perfectly readable.
It is a similar situation with the core with respect to JavaScript versions: to be as universal as possible we constrain ourselves to an elderly variant of JavaScript. But it is not an argument that JavaScript should not continue to advance.
I will say that I actually like the new conditional syntax. I find that it can make a macro or procedure much more readable and understandable (at least for me). Also, from a readability point of view I like the use of <% instead of <$ as it makes the conditional statements popout of the code for me (maybe this is partly due to the fact that I tend to do all of my code composing in Notepad++ where I’ve created a color coding scheme that suits me). This is all going to be extremely helpful for me when I come back to a certain procedure a year or two from now and am trying to remember what it does and why I did it. As a retired VHDL programmer, it just makes it more intuitive to me (fits the way my brain works).
I have only updated a handful of procedure with the new syntax, but I have had no issues with it whatsoever. It does just what I was wanting it to do. The only trip up for me was needing “elseif” instead of the “elsif” of VHDL that I was used to. It took me several minutes to find the muscle memory mistake.
Perhaps you might share the scheme (in another thread) ?
I have thousands of those if you ever run short 
Absolute bane of my life the older I get.
I think that’s a good idea. It’s much better to get this right than to do it immediately.
That’s what versioning is for.
Carried far enough, that logic will say that we don’t need TW because everything it does is simply build atop raw JavaScript. (Or we could go all the way down to NAND gates if we prefer.) The proper questions about syntactic sugar are about how much implementation complexity and how much conceptual space it adds versus how much simplification it introduces for users’ common cases.
To me this new syntax is absolutely a win. Note that I’m someone who strives in his JS to write expression-only code, and use no statements at all beyond high-level definitions. So I almost never use the built-in if-else constructs. But in TW, I’m using way too many <$list> invocations in my templates to hide and show content. These would all be improved with the new syntax.