Thank you @tw-Fred,
You correctly explained the situation and proposed a solution.
Like you said, I don’t think TW needs a new syntax as @Jeremy Ruston proposed. It already has a good established widget syntax. Adding new extra syntax completely different to what we know, makes TW more complicated to learn and use.
Like Fred, Tony, Mario and Mohammad, I think using a completely new syntax like {% is confusing while TW has its own <$widget syntax. I think we should improve current widget syntax like what has been done fro transclude widget in 5.3.0 instead of inventing unfamiliar, inconsistent syntax.
Also, like Fred, I may recommend to ask Evan to rename his $if widget for TW 5.3.2 with something like $iif or something similar. This way both few current users of Evan’s if widget will be happy and TW 5.3.2 will have $if widget.
I think it worth to support core feature. Evan’s $if is an old, unmaintained, buggy widget and it is not popular. I doubt common users (majority of users) even know about this $if widget. My experience shows most common users prefer to install official TW and official plugins and have hesitate, concern when they are going to use third party plugins, specially if it is a JS plugin.
So, even Robin’s implementation is rejected in favor of Evan’s $if widget, I recommend not to include the new
{%into the core and use other approach like what Tony suggested (using custom widgets and other features in TW 5.3.x).
Just to clarify, about my view, in your reply to @jeremyruston I am not at all uncomfortable with the proposed new syntax, because it is not consuming another widget such as the $if widget. However I would appreciate it in wikitext as well.
(= folmula ==)
Perhaps one choice is to subsume evens formulae plugin and if widget into the core, however that would still need work and decisions.
I changed a little bit your above custom widget and it works fine as a custom $if.then
\widget $if.then()
<$parameters filter="[all[current]]">
<$list filter="[subfilter<filter>then[then]else[else]]" variable=slot>
<$slot $name=<<slot>>/>
</$list>
</$parameters>
\end $if.then
<$if.then filter="[all[current]has[switch]]">
<$fill $name=then>then result</$fill>
<$fill $name=else>else result</$fill>
</$if.then>
There have been discussions about implementing the “conditions plugin” into the core. It was rejected, because of the “brittleness” of Evan’s if-widget wikitext and the internal mechanism, they are handled. This mechanism is not “compatible” with the core atm.
I cannot exactly remember why the formula-plugin with the “mushroom” parser was not implemented. But I think it also would have meant to make fundamental changes to the TW core itself. Those changes could not be implemented, because of the time constraints on Evans side.
That’s the Formula plugin which has no bearing on this discussion. Here, we’re talking about (to give it its formal name) the Condition plugin.
.
Thanks. Somehow I managed to miss this response. 
Subject closed, methinks.
@jeremyruston Which I think is copacetic. However, you will have noticed there is some resistance to yet-another-syntax variant. Do you foresee that syntax (and alt grammar) being useful elsewhere going forward? Where?
For what it’s worth, I have put my <$if> widget PR on hold until consensus emerges, by setting it to draft mode so it can’t be merged by mistake. I’ll continue to work on my other TiddlyWiki contributions in the meantime. The options I have seen discussed here that I like (this is not an exhaustive list, as there might be something I missed) are:
<$evanif> or <$eif> or something. Then after renaming the widgets, the upgrade path to TW 5.3.2 would be easy.<$if> widget into a plugin, rather than in the core. It could even be enabled by default, allowing most people to use <$if> without having to do anything special during the upgrade process, but allowing anyone using Evan’s plugin to disable mine and not have to change their existing code.{% if %} syntax – not because I think it’s per se better than an <$if> widget, but because it opens up possibilities for the {% whatever %} syntax to be used for several other things that the widget syntax might currently make more difficult than necessary. (A {% switch variableName %} … {% case value %} syntax comes to mind, for example).Anyway, I’ll be watching this discussion (though not every day), and I won’t merge the PR prematurely. Once there’s general consensus on what to do, I’ll go ahead and go that.
Thanks so much for your work on this Robin @rmunn it is an important feature and you have certainly stimulated the discussion. It may be worth your publishing it as a plugin, even if not compatible with existing ones, so the community can play and comment with your solution. This would solicit feedback and allow you to develop it further and assist in the decisions that need to come.
Thanks again
Good question. The challenge with using the widget based syntax is that it is verbose and finickity. For example, every “if” widget will need the characters filter=... repeated, and every widget needs to be explicitly closed.
For example, here is an example of the widget-based syntax:
\define num() 2
<$if filter="[<num>compare:number:gt[3]]">
<$then><<num>> is greater than 3</$then>
<$elseif filter="[<num>compare:number:gt[2]]"><<num>> is greater than 2</$elseif>
<$elseif filter="[<num>compare:number:gt[1]]"><<num>> is greater than 1</$elseif>
<$elseif filter="[<num>compare:number:gt[0]]"><<num>> is greater than 0</$elseif>
<$else><<num>> is negative or zero</$else>
</$if>
That’s a total of 397 characters. In contrast, the same example using the proposed shortcut syntax is 319 characters, and is much easier to read:
\define num() 2
{% if [<num>compare:number:gt[3]] %}
<<num>> is greater than 3
{% elseif [<num>compare:number:gt[2]] %}<<num>> is greater than 2
{% elseif [<num>compare:number:gt[1]] %}<<num>> is greater than 1
{% elseif [<num>compare:number:gt[0]] %}<<num>> is greater than 0
{% else %}<<num>> is negative or zero
{% endif %}
The roots of this proposal have been in my thoughts for a long time. There are many discussions over the years where I have advocated for the general principle of introducing shortcut syntaxes to more concisely express common idioms that can be done with raw widgets, but this is the first time we have a first firm proposal in that area.
A “shortcut syntax” means a special parse rule that matches instances of a particular syntactic construction. It has to be independent of the existing rules, so we can’t reuse the existing syntax markers << and <$, but need to choose a new way to mark not just these conditional operations, but also future shortcut syntaxes.
As @rmunn notes, a switch/case shortcut syntax would be very helpful and could be readily expressed using a similar shortcut syntax:
{% switch [<myvalue>] %}
{% case "one" %}
Something
{% case "two" %}
Another
{% default %}
More
{% endswitch %}
It’s a big step to introduce such a fundamental new feature, but I think would open the door to further improvements that together would greatly improve the expressiveness and readability of wikitext. A new character sequence like {% is bound to look strange and out of place to all of us familiar with the existing syntax, but it is entirely complementary to the existing syntax, and deals with different situations.
this syntax does seem to be a new beginning of something that is not widgets or filter syntax, which is interesting and can enable other things in the future, though there is a cumulatively increasing barrier to entry for learning new syntax types for new users.
on a separate note, you mention this {% %} as a “shortcut syntax”. does that mean there is a “long form” within the existing syntax that it is abbreviating? if that is the case, i see it as a win-win solution - people could use the new syntax if they are comfortable with it, while still being able to fall back on the widget syntax (which may be more lengthy) while learning or for consistency etc.
Yes, the long form of the conditional shortcut syntax is a series of nested list widgets. You can see how things work by creating a new tiddler in the preview and switching on the preview pane to show the parse tree. Try typing an example of the conditional shortcut syntax and in the preview pane you’ll see a rendering of the corresponding parse tree, showing the underlying widgets.
And the reason this is beneficial, is that the list widget is already (heavily?) optimized. Correct?
(Just so it’s “out there”.)
I’m curious as to whether <% ... %> was also considered and, if so, why it wasn’t selected. It just seems more in line with << ... >> and <$... > ... </$...>. No objection here, just curiousity.
We already have similar wikitext shortcuts in the core, for example the closest are probably {{title}} as a shortcut for a tiddler widget wrapping a transclude widget, and {{{filter}}} as a shortcut for a list widget. As such the proposed {% %} is more consistent in my opinion.
\procedure test(animal)
{% if [<animal>match[Elephant]] %}
It is an elephant
{% elseif [<animal>match[Giraffe]] %}
It is a giraffe
{% else %}
It is completely unknown
{% endif %}
\end
<<test "Giraffe">>
The {% syntax was influenced by templating engines such as Jinja, but I agree that there is a good case for using <% which I had not considered. Perhaps it would better convey that the shortcut syntax is transformed into the underlying widgets.
It might be argued that { is the marker for transclusion within TiddlyWiki, and < is the marker for macros/widgets/variables. As such, { is perhaps not a good match for the conditional shortcut syntax because it has nothing to do with transclusion.
I’d welcome other views on this, and will give it some more thought.
I was thinking more in terms of structure vs content, but I don’t think that breakdown really holds up to closer examination. I do think that those in the know might do well to detail what sorts of other things seem likely to use the new syntax, and see if the whole set seems closer to < or to {. The trouble is that if the answer is “Neither”, the decision would still probably have to come down to one of them, or to [; it’s really hard to imagine adding a fourth symbol.
Agreed, as I asked earlier. @rmunn pointed out switch/case/default. I don’t think I can think of any other possibilities - which doesn’t mean much 
But I agree that <% seems better in the proposed role.
Makes me wonder, is there a case for <{ or {% (transcluded directive?) lurking in the shadows on the horizon? Or is my crystal ball in need of a spit-shine?
