\function foo(pfx,tid) [<tid>get[text]split[ ]encodeuricomponent[]addprefix[%5Bprefix%5B]addsuffix[%5D%5D]] +[decodeuricomponent[]join[ ]addprefix[ ]addprefix<pfx>]
<<foo "stuff things this that the-other" "New Tiddler">>
It’s a bit like storing a filter’s text in a tiddler, perhaps tagged with filter, like the advanced search works. In the production of the string, I need to store not just the “knowns” (static stuff) but calculate/append the dynamic part (essentially the “unknowns”).
Looking at the output, what I have right now seems to work, except for the fact that when the filter is executed, “[prefix[CH1]] [prefix[CH2]] …” are being treated like text, i.e. as full on titles.
It’s an odd problem, but a problem nonetheless.
@andrewg_oz’s idea seems worth a shot. A function[] call will hopefully provide the “inner evaluation” I seem to need. IOW, it might prevent the “treating as titles” problem mentioned above.
I feel as if I may be missing some complexity, but here’s what I’d try:
\function prefixed.with(input) [enlist<input>] :map:flat[all[tiddlers]prefix{!!title}]
{{{ stuff things this that the-other [prefixed.with{!!prefixes}] }}}
{!!prefixes} was just what I used for ease of testing on TW-com, and could of course point to any externally stored list.
That’s the nub, I think: Store a string (with tag:filter) that evaluates the above and produces the desired output. @pmario’s bundler works identically. If I have to store a separate global function, that’s fine too. But I’m having trouble making it work.
Yes, okay, complexity. Hopefully the following will nail it.
Look back to my previous post. While it looks as though the “solution” is correct, what it’s not doing is, evaluating the last three elements in the result. Those prefix operators you’re seeing are simply text being produced from the (let’s call it) outer filter.
So the question is now extended: how to evaluate a filter’s output string, as a filter.
The reason I suggested a global function (aside from reusability and brevity when used as part of a longer filter) is that, once you introduce a :map filter run, it will act on all preceding input. This isn’t necessarily a major issue, but it does mean that any additional titles/filter runs, like @CodaCoder’s stuff things this that the-other, will have to follow the map step:
[[MyPrefixes]get[text]split[ ]] :map:flat[all[tiddlers]prefix{!!title}] stuff things this that the-other
By isolating the :map step in a function with its own selection constructor[enlist{MyPrefixes}] (equivalent, in this case, to [[MyPrefixes]get[text]split[ ]]—though it also allows you to store multi-word prefixes in list format in MyPrefixes) you gain some flexibility in the sequence of filter runs.
You could also define several variants on the same structure and mix and match them within a filter:
Personally, I’ve been using @CodaCoder’s dynamic filter approach to eliminate long strings like [tag[A]] [tag[B]] [tag[C]] -[tag[D]] -[tag[E]] from my own wikis. [has.tag[A B C]] -[has.tag[D E]] feels much neater!
