[v5.3.2-pre] Peeking at the Conditional Shortcut Syntax

#14

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

#15

Was that a bad question of mine?, You dont object?, I will assume you do object :nerd_face:

#16

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.

#17

Don’t be, I used a troublesome “turn of phrase”.

#18

They are also wrong in official docs. I’ll create a PR to fix them.

#19

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

#20

Based on what? Your opinion? That is not reflected at all in my experience.

#21

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.

2 Likes
#22

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.

#23

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. :wink:

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. :rofl: ) 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.

4 Likes
#24

My God, @Springer, post of the week (if not year). Exemplary.

:trophy:

And your cross-disciplinary analogies → NAND gates. Boole and De Morgan would be proud!

#25

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.

1 Like
Final Checks Before Release of v5.3.2
#26

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.

3 Likes
#27

Perhaps you might share the scheme (in another thread) ?

I have thousands of those if you ever run short :laughing:

Absolute bane of my life the older I get.

1 Like
Notepad++ Syntax Highlighting for Tiddlywiki
#29

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.

1 Like
#30

Now the debate has being raised can we please return to my original Topic.

  • I am exploring how and when to use it and its features or even bugs

Can we try and use this in the prerelease and share back here?

My Observations

  • The conditional shortcut syntax adds to the methods we can use to conditionally display content including the list and reveal widgets (also custom widgets)
  • being wiki-text themself we should be able to use this in macros, procedures, transclusions and custom widgets.
  • They leverage the filter once again so filter writing skills are even more important.
  • Except for a leading space before a filter <%if filter%> and <#elseif filter%> no spaces are needed inside the new “elements”, so they can be written more simply than the examples suggest.
  • You do not need new lines when using this unless you want them in the result or for easy of reading.
  • If something is wikified it can contain these new syntax elements, such as the caption field. You could have a short and verbose caption field.
#31

I don’t have much to report except that it works as expected. In a heavily templated wiki, I have a great deal of conditional rendering of content in ViewTemplates. I replaced a number of <$list> widgets with the new syntax and it works as advertised. I haven’t had any need for elseif yet. In the plain if case, it feels slightly more verbose than <$list>...</$list>, but when I have an <$else>, it is less verbose. And in all cases, it is much more obvious what’s happening. I had far too many of scenarios like this:

<$list filter="[some[complex]filter[with]many<clauses>]">
Branch A
</list>
<$list filter="[some[complex]filter[with]!many<clauses>]">
Branch B
</list>

where the only difference between the two filters is the existence of a single !. The new syntax makes these much nicer.

2 Likes
#32

Yes the emptyMessage is the “else” in a list widget which is not as intuitive as the new syntax, the same can be said for the emptyvalue parameter of the set widget.

  • The new custom functions are valuable here as well.
#33

Watch your language, please. Wait until the children are in bed.

#34

Admirable.

Heads-up, everyone “Elvis has ENTERED the building” :wink:

Zackly. Prior to the condition plugin, I was swamped in <$list> and <$reveal> widgets which brought zero semantic relevance to my code (probably negative meaning). Hence I jumped on it the moment I laid eyes on it.

Don’t get me wrong though, I can for a moment stand in @Flibbles shoes and see where he’s coming from. But they don’t actually fit me. I couldn’t wear them all day – knowwhatImean? :stuck_out_tongue_winking_eye: