Title list to string via filters?

[saqimtiaz]

The problem: converting a title list into a string which can later be parsed as a title list.

For example, given the input Tiddler One and TiddlerTwo, convert them into the string [[Tiddler One]] TiddlerTwo

This comes up fairly frequently using <$action-createtiddler> or <$action-setfield> when using <$action-listops> isn't an option.

Is there a way to do this with filters without having to resort to macros?

If not, I suggest we add a filter that offers an affordance for it.

It could take them form of:

• a list-to-string filter, that is a filter that turns all of its input into a string in title list format, OR
• a filter that works on single titles, encapsulating them in square brackets if the title contains spaces. This would likely be more versatile. One could then use the following to convert the input into a string representing a title list: +[encapsulate[]join[ ]]

Note I haven't given any thought to naming. It also occurs to me that the "encapsulate" option could also be implemented as format:titlelist[]

Thoughts @Jermolene ?

[pmario]

In normal cases I use "$set name filter" to get this conversion

<$set name=xx filter="[tag[a]]">
<$text text=<<xx>>/>
<$set>

[saqimtiaz]

@pmario that is clever!

However, the need for an extra widget is quite unfortunate. Since title lists are an integral part of working with filters I think we need better affordances for such use cases.

[pmario]

However, the need for an extra widget is quite unfortunate. Since title lists are an integral part of working with filters I think we need better affordances for such use cases.

That's right and I'm in favour of a filter, that gives us this info. Especially since $vars doesn't do the trick.

<$vars xx={{{ [tag[a]] }}}>
<$text text=<<xx>>/>
<$vars>

But with my usecases I also found out, that if I need a "title list string", I need it several times. So having a variable is a plus performance wise. ...

So if we have a filter, we need to make sure, that it is cached, if possible.

[Jermolene]

I agree with the proposal to add a filter operator to stringify a list. @pmario is correct that the <$set filter=> formulation is often preferable because it enables the result to be cached for reuse, and we perhaps might note that in the docs.

[Jermolene]

Do we want to use a suffix for format[] like format:titlelist[] or make it a separate operator?

I think the other suffixes for format all operate on a single list item at a time, where format:titlelist[] would presumably reduce the input list to a single output. I think the implementation would allow that, but it seems confusingly overloaded.

Maybe the operator should be simpler: quotify would operate on each list item separately, adding double square brackets around any items that contain a space. Then one would use it like +[quotify[]join[ ]].

If we did want to make it a reducing operator, then perhaps stringifylist?

[saqimtiaz]

Maybe the operator should be simpler: quotify would operate on each list item separately, adding double square brackets around any items that contain a space. Then one would use it like +[quotify[]join[ ]].

I mentioned this approach in my OP and I do think there is an elegance and versatility to it.

I'll think of alternative names to quotify as I can see users not reading docs and expecting it to add quotes characters.

stringifylist is possibly a bit obtuse for non-technical users.

[kookma]

@pmario is correct that the <$set filter=> formulation is often preferable because it enables the result to be cached for reuse, and we perhaps might note that in the docs.

Does this has a performance effects? It happens a lot to me to use the same filter several times in a small script for example check if it returns any output (1), then perform some tasks (2), ….then perform the second job (3)
So do you recommend to to not hard code the filter and use as a named filter as above?

[Jermolene]

Does this has a performance effects?

As usual with performance issues, it's best to measure things to confirm assumptions, but, in general, evaluating a filter multiple times will be more expensive than evaluating it once. However, in some situations with a large number of items it is possible that the impact of encoding/decoding the list is similar to the impact of evaluating the associated filter.

It happens a lot to me to use the same filter several times in a small script for example check if it returns any output (1), then perform some tasks (2), ….then perform the second job (3)

So do you recommend to to not hard code the filter and use as a named filter as above?

With the provisos that we've noted, a cautious "yes".

[pmario]

As usual with performance issues, it's best to measure things to confirm assumptions, but, in general, evaluating a filter multiple times will be more expensive than evaluating it once. However, in some situations with a large number of items it is possible that the impact of encoding/decoding the list is similar to the impact of evaluating the associated filter.

I did make some measurements and I can say: As soon as you have several hundred tiddlers the [enlist<myList>] is much faster as executing filters. ...

I did play with the filter for the "Recent Tab", which can be a "main cause" of slow UI feedback. ... I'll create a new issue soon. But more testing is needed with eachday and sameday ... It will be tricky

[pmario]

.. the <$set filter=> formulation is often preferable because it enables the result to be cached for reuse, and we perhaps might note that in the docs.

PR will be created soon.

[saqimtiaz]

@pmario I have a PR almost finished for the new filter, docs need a bit more polish, the rest is there.

Let me know if I should discontinue work on it.

[saqimtiaz]

@pmario I've pushed my work so far: #5665

I think the name of the operator needs further consideration, and I still need to add some more info to the docs.

[pmario]

sorry for the confusion: Here is my PR: #5666

I think it's only triggered by your issue here. Not directly related to.

[saqimtiaz]

@pmario no worries! Just happy we didn't duplicate any work :)