How reset a variable to its outer scope?

[twMat]

Basically; I’m naming a variable tag - but I still want to use the tag macro! - How?

Phrased more generally; I’m overwriting a TW native variable name but I want to temporarily access that original native variable.

The context makes it so that using the generic name “tag” for my own variable is strongly preferable for clarity. So I get a situation equivalent of this (the $let is just to illustrate here that tag is a variable):

<$let tag=foo>
<$transclude $variable=tag tag=<<tag>> /> (hoping $variable=tag refers to the macro)
</$let>

…which unsurprisingly just transcludes my tag variable and ignores the param.

So I would need something that “resets” the variable, to fall back on its previous value:

<$let tag=foo >
<$let mytag=<<tag>>
	tag="resetvariable"
>
<$transclude $variable=tag tag=<<mytag>> />
</$let>
</$let>

Is anything like that possible?

Any other solution? I did try to use the deprecated macrocallwidget instead but same resuls.

Thanks!

[saqimtiaz]

Save the core tag macro under a different variable name

<$let core-tag=<<tag>> tag="foo" >
    <$transclude $variable="core-tag"  />
</$let>

[twMat]

Thank you but that does not seem to work because it is really this situation:

<$let tag=foo > - This is the environment!
<$let core-tag=<<tag>> >
    <$transclude $variable="core-tag" tag=<<tag>> />
</$let>
</$let>

[saqimtiaz]

The order is important, you need to save the core tag macro under a different variable name before you redefine it.

Otherwise you can also import the core macro all over again using $import, but that will overwrite the tag variable that you have previously defined unless you save that under a different name.

[twMat]

Another attempt that does not work:

<$let tag=foo > - This is the environment!

<$let temp=tag   tag=<<tag>>   core-tag=<<temp>> >
    <$transclude $variable="core-tag"  tag=<<tag>>/>
</$let>

</$let>

[Scott_Sauyet]

@saqimtiaz

Save the core tag macro under a different variable name

While that certainly looks right to me, something isn’t working:

I thought maybe it had to do with the use of the parameter named “tag” in the tag macro, but the same thing happens with colour, whose parameter is “name”:

It seems that when you do this, the parameters supplied are ignored and it uses its default.

I haven’t checked if this is something recently broken, or if this is long-standing behavior.

The same is true in 5.3.3 and 5.3.1.

[saqimtiaz]

@Scott_Sauyet

It seems that when you do this, the parameters supplied are ignored and it uses its default.

It could be that the redefined variable is not internally identified as a macro and therefore there is no parameter processing.

In the case of the tag macro the workaround would be to set the currentTiddler variable to the desired tag before calling the renamed tag macro.

[Scott_Sauyet]

@saqimtiaz

It could be that the redefined variable is not internally identified as a macro and therefore there is no parameter processing.

That makes sense. While this sounds like a significant bug to me, I have no idea if there’s a simple fix or if it would require a major overhaul.

@saqimtiaz

In the case of the tag macro the workaround would be to set the currentTiddler variable to the desired tag before calling the renamed tag macro.

I guess, but that’s a pretty ugly hack.

[CodaCoder]

I don’t see anything wrong with @saqimtiaz’s code. I do this a lot – caching/saving a context temporarily then having it reinstated when returning to the outer scope.

[TW_Tones]

To me the tag macro is not a variable as much as, a macro that displays something, the tag pill, of current tiddler by default.

• I would store the title, as a variable or avoid overwriting the current tiddler and use the tag macro with or without it’s parameter only at the point of display.
  • <$macrocall $name=tag tag=<<varname/>

[saqimtiaz]

@Scott_Sauyet

That makes sense. While this sounds like a significant bug to me, I have no idea if there’s a simple fix or if it would require a major overhaul.

I haven’t had the opportunity to peek at the code, but on further reflection the problem seems rather obvious and has two components:

• The $let and $set widgets do not have the ability to declare a variable that should be considered a procedure/function/widget.
• When we assign a new variable equals to a macro, we are in fact assigning the value of the macro, i.e. the body, to the new variable. The information about the parameters is lost.

[TW_Tones]

Jeremy had at one stage suggested we may be able to add a feature to change flags on variables internally to alter how they are seen, but as you say the parameters, scope and context could make it complex and of less value.

• I think there is an argument that there exists alternate code patterns that can give the desired outcomes by other means.

As we know macros and procedures need to be forcibly wikified before their result is used as a variable, where functions and backtick attributes overcome this.

• I expect some interesting code patterns could be made leveraging these qualities. See the new transclude $variable syntax.

[saqimtiaz]

@TW_Tones

I think there is an argument that there exists alternate code patterns that can give the desired outcomes by other means.

Agreed. In the context of this thread that is difficult to assess as the author does not provide sufficient context nor a concrete real world example.

[twMat]

the author does not provide sufficient context nor a concrete real world example.

I’ll be back with the very real case!

[twMat]

OK, the real usecase is the just released static plugin.

For anyone willing to actually go there and test it, the idea I’m after is to (in dynamic TW, before export) show tagpills under the respective “tab” seen there. The purpose is to give easy access to the tagpills DnD feature which orders the “faux tiddlers” that are listed in the “faux river” on a per tag basis.

The tiddler showing the tabs - which is also the core tiddler of the plugin - is here. In it, there is \procedure static-tagsbar() were I would like to show the tagpill (under the “toggle” call).

The main reason for wanting to use the name “tag” for my variable is that I want the plugin to be as easy as possible to understand. It is a small plugin but it is IMO complex and has quite a few things that people may not be used to.