Advanced Search in Fields Plugin: v0.2.0

Advanced Search in Fields Plugin 0.2

  • Tabular and Flat output
  • Sort your results in ascending/descending order
  • Show customized fields for tiddlers in your results

When Shiraz is available on your Tiddlywiki, the Advanced Search in Fields Plugin can produce tabular results! Thanks to Shiraz Dynamic Table, it lets to sort your results in ascending/descending order.


Search in multiple fields and display results in tabular form sort A>Z or Z>A order (using Shiraz)


@Mohammed. This is a useful tool. I’m gonna test it some more in the Shiraz version and comment in a few days.

FYI, yesterday I did test it with a large wiki and it proved very useful. IMO raw regex for fields is actually really good for most searches you’d ever need. I’ll comment more later.


1 Like

There is one problem in large wiki!
The new feature (tubular display) for search in all fields and high number of results like 500+ output or more makes TW slow! One solution is to use the maximum 250 output!
I am experimenting to see how I can improve the performance!

I will soon upload the latest version for testing!

Advanced Search in Fields is ready for test.
See Advanced Search in Fields Plugin: First Experimental Release above!

Screencast v0.2.0



If you’re using links/buttons in a list then use delegation instead:

My searches can return a few thousand results without noticeably affecting the wiki performance.

1 Like

See the screencast above for v0.2.0

I believe the issue is with making several tables, renders thousands of tiddler!
To check this and compare with your solution!

  • install Search as described above in
  • then open $:/AdvancedSearch > Fields and make sure you have selected all fields, case sensitive off
  • next enter this phrase as search string: tid
  • try to change the format plain / tabular
  • note to the rendering delay

Of course this is special case, as we have plus 10 thousands tiddlers with tid in the type field

Tables are not the issue. Browsers can display zillion-row tables with ease.

You said previously 500+ results - let’s not move the goalposts. And rather than me investigate your code, let’s both investigate refactoring a search at

This renders 510 links and I see no noticeable effect on performance:

\define click-actions()
 <$action-navigate $to=<<dom-data-link>> />

<$eventcatcher selector=".my-link" $click=<<click-actions>>>
 <$let f="[all[tiddlers]!is[system]search:text[tiddlywiki]]">
  Count: <$count filter=<<f>>/>
  <$list filter=<<f>> variable=link>
   <div class="my-link" data-link=<<link>>><$text text=<<link>>/></div>

.my-link { color:hotpink; }

You can make the filter return thousands of results and perhaps bring the performance down a little. But I guarantee, if you try the slower one using regular search code it will be much slower.

The key is to look at the dom inspector. In regular code you can see the event wiring – a click handler for each link (510 event handlers!). With $eventcatcher ONE.


Thanks @CodaCoder! I welcome refactoring the code to improve the performance!

The example I given above (search tid in all fields except text) returns 1187 only for type filed! BUT yes lets to limit it to 500+ and less the 600 as your example above!

For advances search this is also very fast! specially if you do not switch the display format from tabular/plain! and use the pagination!

The tabular format in Search plugin uses Shiraz dynamic table and it creates more UI element than the simple $link! So, I believe it reasonable to have lower rendering speed! Let me know, how this can be improved!

1 Like

Refactoring: some items I can improve

  • I think filters can be calculated one time and used with enlist!
  • The lower items per page in tabular format
  • Use simple table (e.g do not display tags column which itself uses filters)