Help with listops and spaces

Developers
#1

Unless I’m missing something, it seems like all the listops operations with subfilter require “pre-processing” to convert titles with spaces into a title list first?

image

Now this example seems stupid, but in reality rather the remove[small dog] would be remove<variable> and it’s just the last part that I’d feed into a $subfilter of a $action-listops widget. It seems like although I have to use a use variables for the names, I then have to have a separate variable each time to store a titlelist version of the same value for subfilter purposes.

I hope that makes sense. For my current project I use a LOT of remove/append/move/putbefore/putafter type operations and I have a lot of variables to add before each operation to separately titlelist format them. Just seems strange that the list operators like append didn’t have a way to handle this.
image
Maybe a future enhancement would be a suffix for these operators to interpret the parameter (operator) as a title list instead of a space-delimited list? Like +[append:list[medium dog]] or something.

#2

The new in 5.2.0 format:titlelist[] version of the format operator seems relevant. But I don’t think you are asking how to do the conversion. Your complaint is that you need a separate variable for the titlelist version of the value?

#3

You could have a function do do the trick instead of a variable in 5.2.0:

\define tiddish(title) [[$title$]]

{{{ [[big dog]] [[small dog]] +[remove<tiddish "small dog">] }}}
#4

@stobot there is a lot of cruft in the listops handling that could be improved. However I think you are running into this issue more so since you are using operators intended to accept lists/arrays of items as the parameter/operand.

remove[] and append[] both accept a list of items as the parameter, in which case they will of necessity already be in title list format.

Alternatively to remove a single item:

[[big dog]] [[small dog]] -[[small dog]]
[[big dog]] [[small dog]] -[<smalldogvar>]
subfilter="-[<smalldogvar>]"

To add an item:

subfilter="newitem [<anotheritem>]"

insertbefore[], putbefore[] etc do not have the same issue as I recall, since they expect a single title as parameter.

1 Like
#5

@btheado Thanks, yes the new operator is very helpful, but my complaint/“identification of an opportunity” was that pre-titlelist-ification was needed and couldn’t be done inline (without pre/external help).

@jypre Thanks, actually that’s a good reminder again that you can now feed parameters into macros within a filter, that will probably be the easiest way to remedy all my existing code, thanks.

@saqimtiaz Thanks, I think mostly I need to get over my (probably) irrational aversion to pre-variables. I’m generally obsessed with performance and low-overhead so I try to strip things down as much as possible. All of my actions for my outliner are like 10 <$set> steps and then one <$action-setfield step, and I’m trying to streamline as much as possible. On that note I’ll have to go back and find that post from a while ago on the <$vars> vs. <$set> performance debate. I will still need a lot of sets because I’m building variables on top of other variables with a lot of regex parsing, but I know there are many of the <$set>s that I can change to <$vars> if they’re better.

Some thoughts on performance
#6

@stobot performance is something I think about a great deal as well, and I think you are facing many of the same questions and challenges that I had with Streams.

I started writing a response but it got long enough that I have posted it separately:

1 Like