Intermediate currentTiddler variable when combining two filter runs

#1

Hi. Suppose I have the tiddler tid1 with contents

* 300 <<tag "keyword">>
* 100 <<tag "keyword">>

and the tiddler tid2 with contents

* 400 <<tag "keyword">>
* 200 <<tag "keyword">>

I want to search for tiddlers containing <<tag "keyword">> and get back-links to it. So my first implementation would be

\define search-string() \<\<tag\s"keyword"\>\>

\define show-backlink()
(<$link to=<<currentTiddler>>><$view field="caption">{{!!title}}</$view></$link>)
\end

Search results (1):

<$list filter="[regexp:text<search-string>]">
	<$list filter="[all[current]get[text]splitregexp[\n]trim[*]regexp<search-string>] +[sort[title]]" variable="line">
     <<line>> <<show-backlink>>  <br/>		
  </$list>
</$list>

The outer list gets target tiddlers and the inner list gets the sorted lines. This gives output in search results (1) in the picture below.

This was ok but it only sorts lines within the same tiddler. (The outer list sorts the tiddlers and the inner list sorts lines within the same tiddlers). But I want to do sort(S) where S should be the union of all line results.

So using the trick from this thread I asked a while ago, by concatenating the results into a single string and then sort, I tried

Search results (2):

<$list filter="[regexp:text<search-string>] 
+[get[text]splitregexp[\n]trim[*]regexp<search-string>addsuffix<show-backlink>] 
+[sort[title]]"  variable="line">
     <<line>><br/>	
</$list>

This sorts the lines correctly as expected. However, as you can see in the picture, the backlinks are not correct. It’s like the currentTiddler variable from [regexp:text<search-string>] is lost when it gets passed to the next filter. Is there any way I can get the backlink to link to the correct tiddlers?

image
image514×884 23.9 KB

Any help is appreciated. (I attached the three tiddlers above in case you need to experiment.)
inline-search.json (1.0 KB)

#2

G’day Pak,

Keeping track of what <<currentTiddler>> is can be pretty challenging.

Let’s look at your first search:

When your “show-backlink” macro is referenced, <<currentTiddler>> is whatever the current item happens to be while looping through all of the items resulting from <$list filter="[regexp:text<search-string>]">.

Let’s look at your second search:

When you reference <<show-backlink>>, inside that $list filter, what is <<currentTiddler>>?

It is the name of the tiddler “tid-search” (i.e. the tiddler that contains all of the stuff you defined for search 2.

Before discussing a fix, let’s make sure all of this is clear first.

Once you understand what is going on, I can walk you through getting you to where you want to be.

Well, at some point, you are going to have an “aha” moment, and it will be pretty awesome. If sooner than later (very different for everybody), then you might just figure this one out on your own. Otherwise, I’m right happy to get you through this one.

#3

Hi @Charlie_Veniot , thank you for the explanation. Yes, now I think I understand why all the links shown are to tid_search. Actually when I remove the second filter and append the macro show-backlink after the first filter like this:

Search results (3):

<$list filter="[regexp:text<search-string>addsuffix<show-backlink>] 
+[sort[title]]"  variable="line">
     <<line>><br/>	
</$list>

It also shows links to tid_search!
image

So there is no way I can store each filter result into currentTiddler (or any variable) and refer to it in the next filter expression?

#4

Of course. At the point the filter is executed, <> = “tid_search”, and that’s what knows at the point that it is referenced.

Sure there’s a way to get what you want, but I’m at the end of my day and just trying to finish something else before bedtime.

What you want to do can certainly be done.

I’ll work on it in the morning as I enjoy my first coffee of the day.

#5

Rats. I won’t be able to sleep with that on my mind.

So I am tossing aside the other stuff I was working on, and going back to this before bed.

I’ll get back with solution in a bit.

#6 
\define search-string() \<\<tag\s"keyword"\>\>

Search results (2):

<$list filter="[regexp:text<search-string>] +[get[text]splitregexp[\n]trim[*]regexp<search-string>] +[sort[title]]"  variable="line">
     <<line>> (<$list filter="[regexp:text<line>]"><$link/>; </$list>)<br>	
</$list>

Take note that in my testing, I created “tid3” as a clone of “tid1”, to setup the code above to handle more than one tiddler having a reference to keyword.

How’s about I let you study that a little, and let me know if you have any questions.

EDIT: attached json with all tiddlers (maybe download and drag to tiddlywiki.com)

tid-search.json (864 Bytes)

#7

Hi @Charlie_Veniot , wow your method works beautifully!

<<line>> (<$list filter="[regexp:text<line>]"><$link/>;

So the idea is not to get backlinks via the filter, but to use the filter results stored in line variable to re-search for the tiddler containing it! (why didn’t I think of that). Thank you very much for your time and effort :slight_smile:

#8

Oh cool. Because so easy for me to get distracted by anything and head into a solution for the totally wrong problem.

Because filtering in TiddlyWiki, I find that a whole ton of fun. Bigly.

I’d say try to see one filter expression as a series of transformations from A-Z. For each step forward in the transformations, whatever existed in the previous steps no longer exists.

So if the final step in the one filter is to get backlinks, then the result is backlinks and none of the stuff before the backlinks. i.e. the stuff before the backlinks was just to get to the backlinks, and that stuff before backlinks is gone.

So $list gets you a list of things that are all of the same “type”. So say a list of all kids in one school.

If you have one filter that gets a list of all kids in one school, and then that same filter gets all of those kids’ parents, the resulting list is the parents. The list of kids was in a previous step of that one filter, and that list of kids is gone because it was just something to get to the list of parents.

So that’s where we get into “nested” lists: a filter for list of kids, and then for each kid a filter for list of parents.

When a final result is a merge of two or more simple lists, there are always multiple ways of nesting the list filters, and the filters will vary as you move them inward/outward of the nested lists.

Something like that …