Using variables/transclusions in the suffix of a filter operator

Developers
#1

Folks,

I am just doing an exploration of apparent limitations within tiddlywiki that I wish to look at documenting within tiddlywiki.

There are a number of Filter Operators that use a suffix to provide additional parameters to that filter operator. A handful just change the way the filter operator works and would be unlikely to need to be replaced with a variable value.

There is however Filter Operators that use a suffix to provide a fieldname or integer, and some filter operators that have rich suffixes that could need to be sourced from a variable or transclusion of a value in a config tiddler.

  • I am looking at documenting a method to permit designs where one or more suffixes to a Filter Operator, can be provided programmatically as a variable or a reference to a title/fieldname
  • I believe the workaround involves using backtick operators to form the required filter then provide that as a parameter to a filter parameter on a widget such as $list.

A better solution?

However I am posting here in the developer forum to see if we could instead keep it simple for users to add to the filter operator syntax to allow a suffix to be set to the value in a variable and/or tiddler reference (by transclusion).

  • This of course requires a core change
  • This may allow a lower cognative load to provide programaticaly determined suffixes to a filter operator.

The following is a list of operators that may require such a facility in no particular order;

suffix Operator
search-replace Operator
search Operator
sameday Operator
replace Operator
removesuffix Operator
removeprefix Operator
regexp Operator
putlast Operator
putfirst Operator
putbefore Operator
putafter Operator
prepend Operator
prefix Operator
move Operator
match Operator
jsonset Operator
insertbefore Operator
insertafter Operator

1 Like
#2

I’ve gotten in the habit of using the backtick work-around you suggest (e.g.

filter=`[contains:$(field)$[value]]`

in a context where <<field>> has already been defined) and macro substitution (contains:$field$[value]) before the backticks were an option. But this was certainly a confounding problem earlier in my TW career, and I agree that it’d be very helpful to allow traditional variables as suffixes, at least!

Here’s a slightly longer list of operators that might be affected (unvetted; I just grabbed everything with [has[op-suffix]]):

Suffixed filter operators, hidden for length
3 Likes
#3

Thanks @etardiff

I have a similar list to you, my list was reduced to those above, where one may most likely be inclined to manipulate something in the suffix programaticaly.

  • For example the match operator suffix is only if you may need to change the match to case insensitive which is lmost likely to be hard coded.

Using the backtick method

However the back tick solution, which you illustrated, is quite simple, especialy when directly applied to the filter parameter.

  • On each of the Filter operator documentation tiddlers, the word “suffix” links to “Filter Step”.
  • It may make sense writting a new tiddler called "using operator operator Suffix’s, then linking to or listing tiddlers that a use suffix along with a short description how to use the back tick operators, for programaticaly assigned suffixes.

Perhaps this method is sufficent if documented?