Switch Case Construct

Sometimes adding a :heart: to a post almost trivializes what’s being said – but that statement (i.e. the proposal) is pure gold and a joy to hear. Thanks.

And yes, I noticed \whitepspace being used like that somewhere on TW .com and started using it – good stuff.

You’ve probably seen \whitespace used within a macro definition - the content of the macro is a new parsing context, and so it allows pragmas, but still only at the top.

So this…

Answers this…

Pulling the jigsaw pieces together…

\define my-macro(...)
\if [<currentTiddler>match[yes]]
  <!-- do stuff -->
\else
  <!-- do other stuff -->
\endif
<span> do always </span>
\if <== Error: no can do here
...
\end

It’s “okay” but not as composable as $if widgets (I’m 100% certain you know that, so #just-sayin).

Thanks for clarification @jeremyruston


The jigsaw pieces you’re pulling together is for how pragmas currently work, yes, but Jeremy notes a new take on this, i.e

…that we allow pragmas to appear anywhere in a tiddler, with only some pragmas needing to be at the top of the tiddler

Sounds very good.

Indeed. I gave the syntax above as an example of a wikitext syntax for these things, not as a finished proposal. One could come up with an inline-able variant, but it would be likely to be more verbose.

Likely. But write up some pseudocode and let’s see how you see it working (and have Jeremy confirm it). It’s hard impractical to comment on commentary without a worked example to rip apart. :wink:

All,

I can see value in a pragma style if then else, it makes writing macro style solutions nice but for many structures we are likely to have case where we want the if then else structures throughout the wiki text.

It seems to me the quickest path is to provide the following; one could reuse the list widget code or simply provide an alias;

  • Alias for $list of $if (may actually use the exact same code as $list)
  • Allow the “template” parameter to have an alias “then” and accept inline text or a variable/macro name eg then=<<macro>>
  • Allow the “emptyMessage” to have an alias “else” - it already accepts litterals, templates or macros.

For example in the following example which is already a reasonable case structure.

Using $if would look like this;

<$set name=input filter="[<input>]uppercase[]]">
<$if filter="[<input>match[A]then[Another]]" then="true"></$if>
<$if filter="[<input>match[B]then[Best]]" then="true"></$if>
<$if filter="[<input>match[C]then[Caught]]" then="true"></$if>
<$if filter="[<input>match[D]then[Default]]" then="true"></$if>
</$set>

However the advantage if reusing the $list widget is we gain a lot more we can code “inline”

Or a more complete nested if

<$if filter="[<input>match[A]then[Another]]" then="""
A true wikitext"""
else="""
   Not A Wiki text
   <$if filter="[<input>match[B]then[Best]]" then={{btrue}} else="Not A or B"></$if>
"""
></$if>

But the key features of this solution are

  • It permits nesting via literal, variable or transclusion
  • You can display intermediate results eg: “Not A Wiki text”
  • You can have multiple $if throughout the wikitext without needing to follow macro definitions.
  • $if implies the result is true or false, however we could code “if any” and “if for each”
    • A designer approach to use $if when the result is intended to be true false would help readability eg;
<$if filter="[{$:/config/debug-mode}match[yes]]" then="Show in debug mode"/>
OR
<$if filter="[{$:/config/debug-mode}match[yes]]">
Show in debug mode
</$if>
OR
<$if filter="[{$:/config/debug-mode}match[yes]]" else=<<toggle-debug>> >
Show in debug mode
</$if>

The above is quicker and clearer when using filters in what would be the list widget simply to display conditional content. This is because the result is true or false not a list, the $if suggests it is not a list, although we have available the full $list widget features.