I can't pass a variable as parameter to a function

1

Here’s the example from https://tiddlywiki.com/#Functions

\function .myfun(param:"2")
[<param>multiply[1.5]]
\end

{{{ [.myfun[2]] }}}

It works as expected. I only added a dot to its name.

Now I define a variable:

<$let p=2>
<<p>>
</$let>

This works as expected too.

Now I try to combine these and pass a variable instead of a hardcoded value as parameter to the function:

<$let p=2>
{{{ [.myfun[<<p>>]] }}}
</$let>

Surprisingly, this doesn’t work.

But I’m trying to use a variable inside a filter, perhaps I should do it like this:

<$let p=2>
{{{ [.myfun[<p>]] }}}
</$let>

This doesn’t work either.

Frankly, I feel like the guy from this old video https://m.youtube.com/watch?v=pQHX-SjgQvQ

2

You’ve got too many brackets — try [.myfun<p>] instead.

Those Pesky Brackets is a good reference for when to use each type of bracket — but the super-short rule is that you should never be nesting them inside a filter.

:white_check_mark: tag[literal name of the tag]
:white_check_mark: tag<variable>
:x: tag[<variable>]
:white_check_mark: tag{!!fieldname}
:x: tag[{!!fieldname}]

(@Brian_Radspinner, I’m noticing that all your examples are things like <$list filter="[<stuff>]" /> — great as a minimal testcase! But it occurs to me that it might be useful to include things like <$list filter="[tag<stuff>]" /> as well, so it’s more obvious how variables/transclusions are intended to work with filter operators.)

3

You’ve got too many brackets — try [.myfun<p>] instead.

Why can’t the filter parser display such an error message? :pray:

4

That would spare a lot of people a lot of confusion, I’m sure! My non-dev guess is that it won’t happen because there are actually a few instances in which you might legitimately want and need to use operator[<p>] — for instance, because you’re using [search[<p>]] to find all tiddlers containing at least one <p> element in their text field. (I’ve done this before myself!) In this case, you would want the filter to consider <p> a literal string (denoted by the single square brackets around it), not a mistyped reference to a variable called “p”.

So my no-nested-brackets rule is actually a bit of an oversimplication… a less-simplistic rule would be “don’t nest brackets unless you know exactly why this case is an exception.” :wink: And unfortunately, I don’t think it’s possible to write an error message that wouldn’t throw false positives for these edge cases.

5

Hi @etardiff that is an accurate and very cogent summary of the situation.

It did set me wondering if there might be scope for exploring warnings that could be given for constructions that are known to be ambiguous:

  • Literal operand values that start and end with matching [], <> or {} brackets
  • Literal operand values that contain !! or ##

But perhaps the real challenge would be figuring out the best way to present these warnings to users, given the possibility of false positives.

An alternative approach could be to extend the “Filter” tab of advanced search with tools that give users more visibility of how filters have been parsed and the values that were passed through each operator. Such a visualisation might make it easier to understand parsing errors.

6

Even obvious wikitext parsing errors can show up in a way that is umm… maybe more end user friendly (as in they don’t look like a big scary red modal window with cryptic text), but not really programmer friendly.

I even have a fresh example to ilustrate it.

I was converting this trivial example:

<$let foo="bar">
<<foo>>
</$let>

to use the $set widget instead, but I did it by hand and forgot to change the last line before saving.

So instead of

<$set name="foo" value="bar">
<<foo>>
</$set>

I ended with

<$set name="foo" value="bar">
<<foo>>
</$let>

which rendered as

bar </$let>

Of course in this case the hint is on screen, but it still took me more than a moment to figure it out. And I’m sure it took longer than if I would’ve seen a proper wikitext parsing error message like

`<$set>` tag started at line 1 is not closed

Is there anything I can do here to get more “technical” feedback, even if it will be more detailed and less “user friendly”?

7

I think good syntax highlighting in the editor could go a long way to informing an editor of wikitext.