[IDEA] Textify filter output

[twMat]

(IMO, this borders on being a "bug")

I wish for a convenient way to display calculated output as text. Currently, filters always output links when the output quite often is not supposed to link to anything. It is often too messy and inconvenient to go the full route with a ListWidget+ViewWidget. For example:

;Total time: <<total>> h.
:Physics {{{ [<total>multiply[.7]round[]] }}} h
:Chemistry {{{ [<total>multiply[.3]round[]] }}} h

Thus, I need a smooth way to "de-linkify" the output, ideally both for filtered transclusion and for the ListWidget.

One syntactic idea would be to prefix the filtered transclusion or even the full ListWidget with a ~, e.g

~{{{ ... }}} and ~<$list ....

This ~ would distribute onto all output items.

Reflection I believe "delikification" has been neglected because filters, in the early days, were mostly limited to dealing with actual tiddler titles (i.e title links). As the filter language has become much more powerful it is now clear that we need this possibility.

[pmario]

Tested on https://tiddlywiki.com

first version: ... no links for whole tiddler

\define tv-wikilinks() no

{{{[tag[HelloThere]]}}}

docs: https://tiddlywiki.com/#tv-wikilinks%20Variable:%5B%5Btv-wikilinks%20Variable%5D%5D%20%5B%5Btv-wikilinks%20Variable%20(Examples)%5D%5D

second: per filtered transclusion

{{{[tag[HelloThere]]||noLinks}}}

title: noLinks

<$view format=text field=title/>, 

IMO that should do the tricks. Download the zip below. it contains the tids for easy testing :)

filtered-transclusion-no-link.zip

[saqimtiaz]

I do something like this: {{{[tag[HelloThere]]||$:/noLinks}}}

or

<$text text={{{[tag[HelloThere]]}}}/>

Edit: the second one is for when you're expecting a singular output.

[Jermolene]

Hi @twMat I'd definitely now consider it a mistake that the default template for the list widget generates links, and I appreciate the need for a concise means of rendering a text representation of the list output.

@saqimtiaz's suggestions are the most concise workarounds we have now. I do quite like the idea of adding support for ~ prefix to suppress the links but recognise that it adds complexity to support a fairly narrow usecase. It would probably need to be implemented using the tv-wikilinks trick so that things like ~{{{ [tag[Features]] || MyTemplate}} will have the expected results if the template renders links.

Perhaps it would be simpler and less ambiguous to implement this as a default template that is used if the template title is zero length, for example {{{ [tag[Features]] ||}}}. But again, it adds complexity and isn't particularly discoverable.

[twMat]

Guys, great input and it sufficiently solves my immediate need. Still it would be desirable with a "featured" solution.

Could perhaps boolean attributes, and a syntax therefore, be introduced to specify a template in a more user friendly way? I.e it is not good UI to burden the user with having to construct even the most basic templates for himself. Further, there is a problem with naming templates as evidenced from the spontaneous title suggestions above ( @pmario's noLinks vs. @saqimtiaz' $:/noLinks). This problem comes from the fact that they are actual tiddlers, not commands or attributes. Boolean attributes would be a friendly way to instead reference such templates, and we could feature a few more basic use case templates e.g:

• links (default)
• text
• csv (inline comma separated list, ref)
• bullets (bullet list)
• tabbed (equi-distantly tabbed values)
• ...maybe even table or tablerow

which would use a new syntax, e.g

• {{text{ ... }}} (has analogies to [operator[...]])
  or
• {{{ ... || text }}} or {{{ ... || :text }}} i.e these are treated as reserved keywords (or else falls back to be interpreted as tiddler titles).

.....

...'cos I'm guessing they could not be filter operators, right? {{{ ... +[:text[]] }}} i.e a prefixing :, or some other string, as a "format indicator".

If that were possible it could simplify some "string manipulation cases" I've come upon where manipulating full texts in listwidgets to extract and merge stuff can give problematic output like [[foo [[bar baz]]]]

[Jermolene]

Hi @twMat one fundamental challenge is that usability suggests offering simple template titles like "text", "links" etc. but the templates themselves need to be stored in tiddlers with titles that don't clash with titles that a user might employ. Thus we need a way of mapping the template nickname with the title of the template itself. A reasonable approach would be to use a namespace such as $:/config/QuickTemplates/<name-of-template>, thus $:/config/QuickTemplates/text would contain the template for rendering the list as "text".

It's worth noting that behind the scenes the parser for "filtered transclusion" accepts several options that are not currently used:

{{{ [tag[docs]] }}}
{{{ [tag[docs]] |tooltip}}}
{{{ [tag[docs]] ||TemplateTitle}}}
{{{ [tag[docs]] |tooltip||TemplateTitle}}}
{{{ [tag[docs]] }}width:40;height:50;}.class.class

Currently, the tooltip, styles and classes are passed as attributes to the list widget, which ignores them. The implication is that we can reuse any of those syntactic elements without clashing with existing wikitext.

So, for example, we could redefine the "tooltip" to be an optional title of a quick template:

{{{ [tag[docs] |text}}}

The regexp using for parsing filtered transclusions is:

\{\{\{([^\|]+?)(?:\|([^\|\{\}]+))?(?:\|\|([^\|\{\}]+))?\}\}([^\}]*)\}(?:\.(\S+))?(?:\r?\n|$)

Here's a graphical view:

Annoyingly, the parser for simple transclusions doesn't include the tooltip, style and class elements but I think we could probably extend the same idea there.

[twMat]

{{{ [tag[docs]] |text}}}

Absolutely beautiful!

Apropos pipe chars I just want to call attention to #4462 , i.e just to ensure there's no conflict caused. Maybe that issue is unrelated, I can't tell.

[Jermolene]

(I'll add a note to #4462)

[pmario]

Annoyingly, the parser for simple transclusions doesn't include the tooltip, style and class elements but I think we could probably extend the same idea there.

So {{title |inline}} or {{title |block}} would be a possibility too, because there is a difference between wikitext and transclusion widget. block and inline could be keywords, which are directly understood by the parser and everything else is a "quicktemplate"

[pmario]

On the other hand, imo the transclude-widget may need a new "quicktemplate" parameter, to have feature parity this way too ?!

[twMat]

Apropos namespaces and $:/config/QuickTemplates/<name-of-template>;

My interpretation is that these "filter output templates" would just be viewtemplates, very much comparable to other viewtemplates. For example, I've seen cases where the user wanted the filter output styled like tag pills. So maybe the "filter output templates" names can stay close to the existing viewtemplate namespaces? Individual viewtemplates are named:

$:/core/ui/ViewTemplate/<name-of-template>

...and I note we use this structure for configuring the main ViewTemplate and main EditTemplate:

title: $:/config/ui/ViewTemplate
text: $:/core/ui/ViewTemplate

So maybe we could use this scheme also for "filter output templates", i.e:

title: $:/config/ui/FilterTemplate/<name-of-template>
text: $:/core/ui/FilterTemplate/<name-of-template>

or possibly just

title: $:/config/ui/ViewTemplate/<name-of-template>
text: $:/core/ui/ViewTemplate/<name-of-template>

[Jermolene]

Hi @pmario

So {{title |inline}} or {{title |block}} would be a possibility too, because there is a difference between wikitext and transclusion widget. block and inline could be keywords, which are directly understood by the parser and everything else is a "quicktemplate"

If we're using the vertical bar to delimit the quick template name as per my proposal above, the problem is that it isn't possible to implement your inline vs. block proposal as a template. Inline vs. block is implemented as attributes of the transclude widget.

[Jermolene]

Hi @twMat I wouldn't think of these as "view templates" so much as templates. The argument for using the $:/core/ui/ViewTemplate/ prefix could just as easily be made for any other prefix containing templates. The other problem is that the $:/core/ui/ViewTemplate/ prefix isn't special in the context of view templates, it's the tag that's special. Making the prefix special as well seems complex.

[twMat]

@Jermolene wrote

If we're using the vertical bar to delimit the quick template name as per my proposal above, the problem is that it isn't possible to implement your inline vs. block proposal as a template. Inline vs. block is implemented as attributes of the transclude widget.

Does this mean that my suggestions for e.g "csv" and "bulletlist" templates - i.e templates that rely on a distinction between inline and block - are not possible?

[Jermolene]

Does this mean that my suggestions for e.g "csv" and "bulletlist" templates - i.e templates that rely on a distinction between inline and block - are not possible?

Whether the transclusion is in inline or block mode is determined by the transclusion itself. A transclusion preceded and followed by a blank line will be in block mode while transclusions within a run of text will be in inline mode. So, such templates might only work as expected in inline mode.

[twMat]

OK, just like the regular transclusion behaviour then which, presumably, the user is familiar with so that's fully sufficient IMO.

[pmario]

If we're using the vertical bar to delimit the quick template name as per my proposal above, the problem is that it isn't possible to implement your inline vs. block proposal as a template. Inline vs. block is implemented as attributes of the transclude widget.

@Jermolene ... I know, that it's an inconsistency. .. BUT we have had a lot of discussions, that users have to use the transclude-widget, because the more convenient wikisyntax {{tidler}} can't deal with it.

It's the parser, which needs to set the parameters according to the code. So if it's inline or block it uses it for mode=inline or block or block. .. Everything else will be template="except-inline-or-block"

I did have a look at the code. It should be possible, since transcludeblock.js and transcludeinline.js contain almost the same code. ... At least is seems to be worth a try.

[Jermolene]

Hi @pmario for templates other than the special "inline" and "block" ones, how would one control whether inline or block mode was used to parse the template? I understand the motivation but I think this is a non-starter: it's too inconsistent and mixes different features into the same parameter.

[rmunn]

The way that https://github.com/Jermolene/TiddlyWiki5/commit/ae13a0fee118c50169b7835c950df1dade33788f adds a raw-text output to macro calls suggests a mechanism that might be good for the list widget too, and maybe even the {{{ }}} syntax though it's slightly less obvious there how to proceed. I liked the ~ prefix idea at first, but it's not expandable, and the |text suggestion is, IMHO, better because it offers the possibility of future expansions. (E.g., we might add |transclude to have each title automatically transcluded or something, though that's just an off-the-cuff suggestion and I don't know if it's actually useful or a terrible idea).

But I would indeed like something to be available here. I've found myself using the $list & $view solution too many times, and that's overkill for many use cases.

[Alzacon]

Hi.

I agree with @rmunn in adding raw-text output.

I understand this:

Does this mean that my suggestions for e.g "csv" and "bulletlist" templates - i.e templates that rely on a distinction between inline and block - are not possible?

Whether the transclusion is in inline or block mode is determined by the transclusion itself. A transclusion preceded and followed by a blank line will be in block mode while transclusions within a run of text will be in inline mode. So, such templates might only work as expected in inline mode.

But when I tried transclude {{ $:/palettes/Vanilla##alert-background }} "in block mode", I expected the valor of the index, #ffe476, but the result is the ordered list:

1. ffe476

   This case can be a bit special, but this will happen with transclusion of elements with syntax similar to WikiText.

[twMat]

Grasping for straws here but maybe the problem could be postponed into to the rendering of the output instead of inside the listwidget? For example make any link prefixed with ~ simply not be a link. So the following would not end up as links - and that has nothing to do with the actual filtering or listwidget:

{{{asd fdfs dsfd +[addprefix[~]] }}}

Given the already special role of the ~ character in TW, I'd think it is extremely rare that people deliberately use it as a prefix in links.

[pmario]

@twMat According to your comment at Talk, I think this issue can be closed. right?

[pmario]

The idea allowing templates for {{{ xx }}} as developed in the discussion may be a new issue. I think the OP of this issue is solved with v5.3.0

[pmario]

@twMat ... IMO the OP problem can be solved like this with \functions

eg: f.70(x) and f.30(x) are 2 function calls, that allow an "x" parameter. If x is empty, it uses the global "total" variable. If x has a value it will be used instead

\define total() 2.7

\function f.70(x) [<x>is[blank]then<total>else<x>multiply[.7]round[]]
\function f.30(x) [<x>is[blank]then<total>else<x>multiply[.3]round[]]

;Total time: <<total>> h.
:Physics <<f.70 "7">> h
:Chemistry <<f.30>> h