Misunderstanding :map filter run prefix

#1

I’m trying to figure out what is wrong with my understanding of the :map filter run prefix.

Given this definition:

\function by.caption() [tag[Filter Operators]caption<currentTiddler>]

I would expect these two to generate the same result:

''a'': <$let currentTiddler="all">{{{ [by.caption[]] }}}</$let>

''b'': {{{ [[all]] :map[by.caption[]] }}}

But they do not:

a: all Operator

b:

I’m must be misreading the documentation, but I don’t see how.:

The following variables are available within the filter run:

  • currentTiddler - the input title
  • …

Can anyone explain?

MapMisunderstanding.json (518 Bytes)

#2

The problem doesn’t come from <currentTiddler> in the map filter run. You can see it works right if you replace your function by:

\function by.caption() [<currentTiddler>]

Then a and b give the same result: all.

The problem resides in the function input titles. Quoting Filter Operators doc:

Important: In general, each first filter step of a filter run not given any input titles receives the output of [all[tiddlers]] as its input.

So, what example a really does is:

[all[tiddlers]tag[Filter Operators]caption<currentTiddler>]

But the :map filter run already has an input, so [all[tiddlers]] is not implicitly added.

If you change the function to:

\function by.caption() [all[tiddlers]tag[Filter Operators]caption<currentTiddler>]

Then both examples return the expected result.

Hope I was clear enough to explain what’s going on… :sweat_smile:

Fred

3 Likes
#3

I did create a new PR with a slight DOCS improvement. [DOCS] make Filter Operators initial filter run assumption more visible by pmario · Pull Request #8969 · TiddlyWiki/TiddlyWiki5 · GitHub

418375762-253b8556-eb65-4fbf-a9e4-30b5e899fefe
418375762-253b8556-eb65-4fbf-a9e4-30b5e899fefe1694×329 17.2 KB

3 Likes
#4

Oh, of course. I’ve been bitten by that before. I’m not sure why it hasn’t sunk in as deeply as I feel it should have.

Thank you very much for the help.

1 Like
#5

With Multiple filter runs in a single filter, That input can be empty or null and NOT receives the output of [all[tiddlers]]

Personaly I have always thought of all[tiddlers] as the default start for a filter not a filter run. But even that is not totaly accurate.

#6

Thanks for the heads up @TW_Tones!

I ran some tests and here are the results:

prefix shortcut fed with [all[tiddlers]]?
:all = yes
:and + no
:cascade ?
:else ~ yes
:except - yes
:filter yes
:intersection yes
:map no
:or no prefix yes
:reduce no
:sort ?
:then = yes

@TW_Tones does it match your own knowledge?
Maybe other contributors can complete/proof-check above table?

Thanks in advance

Fred

#7

Fred, A quick glance at this you can see the logic behind it. Map and reduce are designed to act on what they are fed and expect something prior to feed them with titles so we dont want these being populated with all titles, similarly :and is a comparison.

The filter runs as a rule accept as input: the filter output of all previous runs so far, this is infact what a filter is, but the question is what to do if there is no source list, when does it make sence to default to all tiddlers if there is not titles initialy.

Sadly there seem not to be a clear way to express these differences.