Hi @CodaCoder,
Thank you for your clear points. What I wrote is my technical point of view. Absolutely there is no debate.
The good news is every user can live with existing features. When a new feature is introduced, TiddlyWiki does not force to use it, because all old features, functionality are still there. So, all people with all types of opinions can still use TiddlyWiki.
I understand (and greatly appreciate!) that this is the general design principle behind TW, but it isn’t always the case - that’s why @CodaCoder opened the thread. If future versions of the core do implement a new widget with the same name as the one defined in the plugin we’re using and it doesn’t function the same way, we will by definition be losing functionality we have at the moment.
I think you implied earlier in the thread that we don’t need to upgrade affected wikis past 5.3.1… and while that is technically true, one of the reasons I’d really like to be able to keep up with new releases is because a bug introduced in 5.3.0 did remove a previous functionality I’d already built into my wiki. I’m optimistic that this will be addressed eventually: Jeremy and our other contributing developers have always been very committed to fixing bugs. But if I have to stick with 5.3.1 indefinitely, I’ll lose access to future fixes as well as future improvements.
If @rmunn 's widget were being proposed as an official plugin (alongside staples like CodeMirror and the menubar) rather than a core feature, I’d be very happy with it in its current state!
And the link @pmario suggested: Jeremy’s PR also allows older, working code to survive:
\procedure test(animal)
{% if [<animal>match[Elephant]] %}
It is an elephant
{% else %}
{% if [<animal>match[Giraffe]] %}
It is a giraffe
{% else %}
It is completely unknown
{% endif %}
{% endif %}
\end
<<test "Giraffe">>
<<test "Elephant">>
<<test "Antelope">>
Disclaimer: I have never used Evan Balster’s plugin, so I may stance nonsense here. If so, please tell me.
First let me say I really crave for a <$if> widget, and I think it’s such a basic building block that it should belong in the core.
Next I don’t think adding a new syntax as per @jeremyruston’s PR is the right thing to do, as TW already provides a perfect syntax for this: widgets. It’s even what this threat is all about: the <$if> widget is so obviously the right solution that several people used it in incompatible ways.
Also there’s a large code base already using Evan Balster’s plugin, and merging @rmunn’s work in the core would break this code base.
So, how could we make both Evan Balster’s plugin and @rmunn’s work cohabit?
A proposed solution could be to provide:
- a new version of Evan Balster’s plugin renaming its widgets to something else (let’s say
<$eb.if>,<$eb.else>, … - and also a migration tool that could transform every
<$if>to the new widget name, something along the lines of @Mohammad’s Commander.
No new features, just a widget renaming and a code transformation tool.
My 2 cents,
Fred
3 Likes
Some latteral thinking here but I would emphasis the 5.3.x improvments offer other lateral and innovative ways to handle this. For example it should be quite easy to redefine evans if to a new name, or the opposite, redefine a core $if to another name leaving evans to dominate if already in use. With custom and installable widgets.
- Although I am arguing that we should consider an $if widgets, or by another name BUT develop a more mature solution to justify the adoption of an $if widget, especialy if it clashes with the only effective version that has being available for a long time, in evans plugin. Future backwards compatibility means we should be careful here.
You can see here Further use of $params with $parameters widget a detailed discussion on aspects of the 5.3.x features to pass an arbitary number of parameters from one widget or procedure to another. Just what we need to redefine a widget.
I can forsee an option to choose ones $if widget “provider”.
1 Like
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.
1 Like
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).
1 Like
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.
- Evans plugin is successful because it introduces the mushroom braces
(= folmula ==)
Perhaps one choice is to subsume evens formulae plugin and if widget into the core, however that would still need work and decisions.
2 Likes
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.
.
2 Likes
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:
- A widget renaming tool, so that people using Evan’s existing plugin can easily rename his widgets to
<$evanif>or<$eif>or something. Then after renaming the widgets, the upgrade path to TW 5.3.2 would be easy. - Putting my
<$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. - Jeremy Ruston’s proposed
{% 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.
4 Likes
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.
4 Likes
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.
1 Like
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.
1 Like
And the reason this is beneficial, is that the list widget is already (heavily?) optimized. Correct?
(Just so it’s “out there”.)