Yes, precisely what I'm talking about. It seems clearly useful to have a
variable target, but it feels (to me) like a hack to set currentTiddler to
achieve that effect. Besides, doing so precludes expressions that depend on
currentTiddler AND some other variable. I think it would be incredibly
useful to be able to "dereference" any variable - not just currentTiddler -
in inline transclusion. I'm happy to submit a pull request, I'm just asking
how to go about creating such a feature, or why it's unnecessary or a bad
idea.
On Wednesday, November 2, 2016 at 5:54:40 PM UTC-4, BJ wrote:
>
> At present we use the currentTiddler variable in this way:
>
> {{!!field}}
>
> is, in psuedo code, {{<<currentTiddler>>!!field}}
>
>
> so if you have a value in a variable 'myvar' you can do
> {{<<myvar>>!!field}} as
>
>
> <$vars currentTiddler=<<myvar>>/>
> {{!!field}}
> </$vars>
>
> all the best BJ
>
> On Wednesday, November 2, 2016 at 7:30:23 PM UTC, [email protected] wrote:
>>
>> I'm looking in to indirect inline transclusion with the curly-brace
>> syntax, a la {{somevar->field}} which, if somevar is set to
>> "tiddlername" (e.g. with <$set/>) then it would resolve to the same thing
>> as {{tiddlername!!field}}. I think the arrow operator is reasonably
>> appropriate. I can imagine a number of useful use cases for this notation.
>>
>> At first I thought I could just modify $:/core/modules/utils/utils.js
>> such as modifying parseTextReference's regex to read (modifications in
>> bold):
>> var reTextRef = /(?:(.*?)!!(.+))*|(?:(.+?)->(.*))*
>> |(?:(.*?)##(.+))|(.*)/mg,
>> ...
>>
>>
>>
>>
>>
>> * if(match[3]) { result.title =
>> this.getVariable(match[3]); } if(match[4]) {
>> result.field = match[4]; }*
>>
>> But then I realized that this is fundamentally impossible since variables
>> are stored in widgets and there's no bound context inside the utils module
>> that can reference the parent widget stack ... right?
>>
>> Is there another approach, or a way to make this approach work? I could
>> define another parser or a new widget but I think it makes most sense as a
>> subtle change from the existing curly-brace syntax. Besides, doing it
>> inside parseTextReference means it would immediately work for everything
>> that calls parseTextReference, such as within filters.
>>
>> Thoughts?
>>
>
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywikidev/64e01b3c-1c0c-44dd-a473-245f62b18017%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
