Would it be possible to write a filter operator that outputs the result of a filter as plain text

Developers
#1

Would it be possible to write a filter operator that outputs the result of a filter as plain text; A simple string after evaluation.

  • This would allow us to avoid the use of the $text widget by producing an output without [[ ]] braces etc resulting in unwanted links during the final render.
  • It would be like an opposite form of the format titlelist.
  • There are places we can’t use the text widget such in attribute values, so such an output would allow the result to be used in more places via a variable.

We could make it a feature and option of the “join[]” operator because this explicitly assembles all results into a string. And may be an appropriate place to join without causing titlelinks.

  • I can see value on a per-title basis, but also on a whole of filter output.
  • This would empower filters to do even more string handling.
  • It would stand to simplify the production of text as a result of a filter

This may be possible already so if you have any ideas please share.

#2

I don’t understand what you are asking. Could you share some examples of input titles and expected output for what you mean? And it sounds like you are able to implement what you want using the text widget? Please share that as well.

For me, runnable code and concrete examples are much easier to understand.

1 Like
#3

Note that all filter expressions evaluate to plain text.

Whether that plain text creates HTML when rendered or plain text depends on how the output of the filter expression is used, and what text content the output consists of. The output of the filter itself is always plain text.

1 Like
#4

I will explain my thoughts with examples soon. I am out bush for now. We can force filter results to use title case and other formats but we cant avoid the output being translated into links or titles.

I know the text widget does this but in most cases you cant use the output of a widget as an attribute value and the text widget is verbose. Wikify even more so and not performant.

It may be addressed in a template.

#5 
\function xx() [tag[HelloThere]format:titlelist[]join[, ]]
\function yy() [tag[HelloThere]join[, ]]

<<xx>>
---
<<yy>>

image
image1666×522 23.6 KB

2 Likes
#6

Functions and join used as variables is it. Thanks @pmario.

In summary

If the information required is available to a filter. ( almost everthing ) including a title list, we can use a function to make the result of that filter, I reiterate “including a list of titles” into a single string or text string, we can use it as a variable, without needing to use the text widget and it is also available to provide the value(s) to an attribute. This includes what I Concider avoiding the “opinionated” (for want of a better word) limiting of filtered transclusions and attribute substitutions to the first value when assigning values to an attribute.

  • its is trivial to take such a compound value or list passed in an attribute and enlist list or split it back into a list.
  • I can use a filter to build a compound list of items such as a css styles to give to the style attribute.
  • I now have a method to solve a whole class of coding challenges

Thanks again @pmario

#7

I am happy I now have an approach to make use of lists stored in variables, and also return a string value as text, without it being formatted into tiddler links. However it seems to me more of a workaround, forced on us because of many references to variables containing a list, only returning the first value.

I currently believe;

  • There seems to be inconsistencies in the rules OR
  • We need to document the resulting behaviours better

I have long felt that a key value of tiddlywiki is its list or set handling as is demonstrated both my filters, tags and the common use, list widget. The fact that now a large majority of the ways we can reference a variable returns only the first item seems to contradict this.

  • Due to backwards compatibility this may be something we can’t address directly.
  • However perhaps we can find another way to address this, be it alternative ways to address variables as possible lists, or at least document it thoroughly.

Inconsistencies and complexity arise when you look at the full suite of ways to set or use variables. As a result demonstrating this needs an exhaustive set of examples which I am exploring off line and it will be somewhat onerouse to document and discuss.

  • Hopefully some of our experienced TW enthusiasts and developers can explore this in their own sandboxes and suggest ways to document this and or identify some ways to address these limitations/inconsistencies.

Using variables to store and instantiate lists.

#8

WAIT WHAAAAAT!!??? CALLING A FUNCTION EVALUATES THE FILTER??? I thought a function was just a way to separately define a filter, a “container” of sorts, mostly syntactic sugar. This was absolute news to me, in spite of having participated in the discussions pre 5.3.0. As I read the docs, this absolutely not evident, probably from lack of examples. Neither of the terms “invoking” nor “transcluding” mean to have something “evaluated” or “run” IMO.

Now the name “function” makes much more sense!

Sorry for going OT but this was a shocker.

To make my post relevant, here’s an old proposal of mine very much in line wiht what you ask for @TW_Tones

1 Like
#9

Yes, this is a wonderful thing, functions can be nested within functions as well, and can be made into named filter operators.

This is a real boon to me, especially with my knowledge and information management experience, because I like building meaningful names. I can build a list of custom and nested filters, that relate to the wikis logic allowing subsequent filters/filter operators to use logical names.

  • Examples in this thread, and later I will publish more elsewhere

For example I can use a function active.todo also as a filter operator, then in the function I can hide how I define an active.todo

\function active.todo() [tag[todo]!is[system]!tag[done]!has[done-date]]

<$list filter="[tag[project-name]active.todo[]]">

</$list>
  • Tag the above as a global “function”
  • So now I can just use active.todo and forget about the details

Textify filter output

Great minds think alike?

As covered in this thread, thanks to @pmario if you have a function, you can use it in filters but also reference it as a variable, and that result is displayed in text. However only the first value is returned.

  • however using join[ ] in the function you can classify the output of the whole filter as a single string, and this function variable returns text.
    • Using either format:titlelist[] to retain it as titles or another “joiner” eg join[ ] or join[|] you can delimit each item in the list, and pass that as a parameter value, that can then be parsed back into a list.
2 Likes