Two more ideas to improve translink macro

[Springer]

I (re)discovered the built-in translink macro recently, and it looks like something I’d use all the time in various templates for tabs and other list-based goodies. Almost always, when I have a transclusion, it’s great to see the title of the transcluded tiddler, to have the link for it right there at the top, and to have an easy visual recognition of the extent/shape of the transclusion.

I see some improvements to this macro were initiated 18+ months ago, in this thread…

But in a couple further ways, it seems translink could still be improved (and is of limited use until then)…:

(1) Let title default to currentTiddler...

The translink macro currently requires the specification of a title (it’s not optional), which is odd. The logic of most other macros and widgets happily defaults to the currentTiddler, as in <<tag>> and <$link/> etc.

I do see that I could set a variable to build a workaround, or invoke translink in the long-form macro transclusion format, as in the following (which works at tw-com, with caveat noted below)…

<$list filter="[tag[$:/tags/Stylesheet]]" >

<$transclude $variable="translink" title=<<currentTiddler>> />

</$list>

… but I’d love for <<translink>> short form to “just work” within a list, because that would be beautiful and elegant. I’ve often put elements together to achieve a similar effect (within tabbed TOC, detail accordions, lists), but it’s cumbersome…

I suspect I see why this default is awkward — namely because if you accidentally invoked it outside the context of a list or other transclusion, you’d end up with an instant russian-doll self-transclusion problem. (Remarkably enough, explicitly self-translinking does NOT crash tiddlywiki dot com, though! It seems to draw further nested iterations only on demand, as one scrolls down, which is very cool!)

At any rate, surely it would be possible to sandbox the self-reference somehow, so that title variable defaults to currentTiddler-ONLYIF-currentTiddler-doesn’t-match-storyTiddler? Or so that translink rendering is halted by a protective “recursive transclusion” alert when storyTiddler includes a “naked” invocation of <<translink>> (or somehow self-references within a list widget, etc.)?

(2) Get translink display to harness cascade conditions

The translink macro doesn’t currently seem to harness the cascade conditions for displaying the transcluded tiddler (in terms of whether/how its view template elements appear). Again, I can and do have workarounds to get the effects I’m looking for, but shouldn’t tapping into the existing cascade be a convenient and powerful feature of translink?

Using the example above at tw-com — the things in the filter condition [tag[$:/tags/Stylesheet]] should all ignore wikitext according to the cascade (so backticks show as backticks, etc. when you open these tiddlers in story river) — but you can see the translink content does NOT follow the that cascade condition for stylesheets.

Of course, there’s already a kind of translink-specific template applied to the body text (the styling that makes it look like the transcluded tiddler text is within a kind of blockquote), but surely we could nest the cascade-obedient rendering of a tiddler within a generic “here’s your recognizable translink” frame?

So…

What do you all think? Do you use translink? Would you use it more, if it did more powerful things out of the box without extra keystrokes?

(PS You can tell my academic semester is over when I show up here for more than a flyover!)

[well-noted]

will return to speak more later, I found translink recently when you found it, think it works great, but also have some thoughts for improvement

[pmario]

Hi, I think that’s a nice write-up. But probably nothing “core related” will happen – It is very likely to be forgotten, except if you publish your own workarounds.

If you think it would make sense for the core, imo you need to create / cross-post a feature request at GitHub.

Just some thoughts.
-m

[vilc]

@Springer

What do you all think? Do you use translink? Would you use it more, if it did more powerful things out of the box without extra keystrokes?

These are some good ideas. I use it from time to time, mainly the inline mode. For the block variant, I have a similar custom procedure (more below). It sure could be made more useful and smart.

title defaulting to currentTiddler
I’m all for it, if it can be technically done without major issues. It would make its use in lists and so on much more practical.

Cascades
In other words, what you suggest is that the “body” of translink macro should be displayed according to the same cascade as the body ViewTemplate, right? This could be useful for “code” tiddlers, I agree.

Styling
The current styling of the translink marcro is of my making, the previous one was very crude. It basically uses the same border and background as a codeblock. I didn’t want to introduce new palette colors, and using the existing palettes, this was one of the combinations that always stands out from the “normal” tiddler background.
When I come to rethink it, it has some disadvantages. Namely, if there are some color-sensitive contents of the translinked tiddler, they might not look good on the code-background, depending on the palette. Perhaps relying on a border alone, without the background, would be better (table-border maybe). There is a lot of room for improvement for sure.

Other features
There are many things the translink macro could do, the problem will be to decide which one of these is universal enough to deserve inclusion in the core. Here are some ideas that I either use (in my custom procedure) or maybe would use if they were easily available:

• Edit button next to the title. This saves me one click when I want to edit what I see, but which is translinked. It looks like this in my custom procedure:
  

  

• Fold/unfold buttons with the ability to set the initial state. Long translinked tiddlers could be e.g. folded by default, or foldable if desired.

All the additional UI elements should probably stay optional, to keep the default look simple.

[Springer]

@pmario

If you think it would make sense for the core, imo you need to create / cross-post a feature request at GitHub.

I thought it might be wise to check in here first — just to see whether others agree that these improvements make sense, and just in case anyone would raise worries about unexpected effects (Surely nobody is running with unspecified <<translink>> in existing wikis, but maybe somebody expects/wants translink transclusions to bypass the cascade, for some reason?)

It’s not high priority, since these are all effects that I have been able to achieve already, just in less efficient ways.

[Springer]

@vilc

Styling
The current styling of the translink marcro is of my making, the previous one was very crude. It basically uses the same border and background as a codeblock. I didn’t want to introduce new palette colors, and using the existing palettes, this was one of the combinations that always stands out from the “normal” tiddler background.
When I come to rethink it, it has some disadvantages. Namely, if there are some color-sensitive contents of the translinked tiddler, they might not look good on the code-background, depending on the palette. Perhaps relying on a border alone, without the background, would be better (table-border maybe). There is a lot of room for improvement for sure.

I think the current styling is pretty good. The bar at left (thanks for this design, @vilc!) is super-effective at signaling something like “quoted content”, and makes it easy to see how far down the transclusion extends.

As you note, it would be better to avoid imposing a single background color (because of color compatibility issues, as you note).

@vilc

Here are some ideas that I either use (in my custom procedure) or maybe would use if they were easily available:

• Edit button …
• Fold/unfold buttons …

I’d be wary of adding too much additional titlebar-like UI into the core / default behavior though. I imagine the ideal core default would look very much like it currently does, when displaying translink content that doesn’t have custom view templates.

(For what it’s worth, I use quite a few custom body templates that build on field contents, each of which applies through cascade conditions, so bypassing the body template cascade makes translink much less useful.)

The main question I have is how easy it would be to have something like a cascade-determined body template render within the translink template. So the tiddler body would like like a slightly narrower (width-wise) version of how it looks in story river, within a “block-quote”-style frame that itself can be modified as needed.

If we did it this way, any user could still tinker with the “translink frame” template as needed, enhancing titlebar with edit and fold buttons (or subtitle, or tag area etc.). Would that dovetail well with your needs?

[Springer]

OK, so I made a demo for myself of a translink ($:/core/macros/translink) that can be invoked as <<translink>> within a list (defaulting to currentTiddler), and where the wiki’s central cascade is harnessed to determine how the transcluded tiddler body is rendered.

UPDATED VERSION HERE

code for better translink

\define translink(title,mode)
\whitespace trim

<$parameters title={{{ [<__title__>!is[blank]else<currentTiddler>] }}} mode={{{ [<__mode__>!is[blank]else[block]] }}}>

<%if [<title>match<storyTiddler>]  %>
<span class="tc-error">{{$:/language/Error/RecursiveTransclusion}}</span>
<% else %>

<$tiddler tiddler=<<title>> >

<%if [<__mode__>!match[inline]] %>

<div class="tc-translink">
<h1><$link/></h1>
{{||$:/core/ui/ViewTemplate/body}}
</div>

<%else%>

<span class="tc-translink">
<$link/> &#32;(<$transclude mode="inline">
<$transclude tiddler="$:/language/MissingTiddler/Hint"/> </$transclude>)
</span>

<% endif %>
</$tiddler>
<% endif %>
</$parameters>
\end

OLD VERSION, for reference only

Tech note
The weird stuff at top (about [<eg>length...]) was needed just to avoid triggering the “recursive error alert” for the Translink macro (Examples) tiddler. (I was determined to display such alerts for cases where <<translink>> is “naked” within a storyTiddler, or where specified title parameter matches storyTiddler title, but the example rendering process at tw-com doesn’t harness currentTiddler… took me a while to figure this out, and it’s such a niche problem!*)

\define translink(title:"",mode:"block")
\whitespace trim

<%if [<eg>length[]match[0]then<__title__>is[blank]then<currentTiddler>match<storyTiddler>] [<__title__>match<storyTiddler>] %>

@@color:red;{{$:/language/Error/RecursiveTransclusion}}@@

<% else %>

<%if [<__title__>is[blank]] %>

<$tiddler tiddler=<<currentTiddler>> >

<%if [<__mode__>!match[inline]] %>

<div class="tc-translink">
<h1><$link/></h1>
{{||$:/core/ui/ViewTemplate/body}}
</div>

<%else%>

<span class="tc-translink">
<$link/>
&#32;(<$transclude mode="inline">
<$transclude tiddler="$:/language/MissingTiddler/Hint"/>
</$transclude>)
</span>

<%endif%>

</$tiddler>

<%else%>

<$list filter="[<__mode__>match[block]]">
<div class="tc-translink">
<div>
<$tiddler tiddler="""$title$""">
<h1><$link/></h1>
{{||$:/core/ui/ViewTemplate/body}}
</$tiddler>
</div>
</div>
</$list>

<$list filter="[<__mode__>match[inline]]">
<span class="tc-translink">
<$link to="""$title$""">
<$text text="""$title$"""/>
</$link>
&#32;(<$transclude tiddler="""$title$""" mode="inline">
<$set name="currentTiddler" value="""$title$"""><$transclude tiddler="$:/language/MissingTiddler/Hint"/></$set>
</$transclude>)
</span>
</$list>

<% endif %>

\end

[vilc]

@Springer

I think the current styling is pretty good. The bar at left (thanks for this design, @vilc!) is super-effective at signaling something like “quoted content”, and makes it easy to see how far down the transclusion extends.

As you note, it would be better to avoid imposing a single background color (because of color compatibility issues, as you note).

I think you’re referring to the quote bar that is shown alongside all examples on tw-com, it’s not a part of the translink macro style. Nevertheless it might be a good alternative to consider. It would indicate the transclusion extent, while not getting in the way with the background color. This leaves us with style for the inline variant of translink – I imagine the only way to indicate it is to use some kind of background or border.

@Springer

If we did it this way, any user could still tinker with the “translink frame” template as needed, enhancing titlebar with edit and fold buttons (or subtitle, or tag area etc.). Would that dovetail well with your needs?

The support for body cascades and defaulting to currentTiddler seem universal enough to be there for everyone. I think the focus should also be on making the customizations easy to introduce, if the core macro is going to stay minimalistic. We should try to achieve that the macro is good to use as is, or modifying/leveraging it is more practical than constructing a custom structure from scratch.

@Springer

OK, so I made a demo

Very nice, it seems to work well with the body cascades.

[well-noted]

@Springer

For what it’s worth, I use quite a few custom body templates that build on field contents, each of which applies through cascade conditions, so bypassing the body template cascade makes translink much less useful

This, .

@Springer

I made a demo

Amazing, I look forward to playing around with it Thanks Springer, once I have I’ll report back.

[Springer]

@vilc

I think you’re referring to the quote bar that is shown alongside all examples on tw-com, it’s not a part of the translink macro style.

Yep, I was assuming that bar at left was part of the translink formatting.

I’m tinkering with some stylesheet variations that build on the “blockquote” visual recognition base…, will share at some point…

[tw-FRed]

@Springer

(It would be more streamlined if there were a way to have title parameter default to currentTiddler, but it seems only to allow a literal string, yes?)

It’s possible to define a variable default value for a procedure parameter with a \parameters pragma or a <$parameters> widget:

Example from tiddlywiki.com:

\procedure myproc()
<$parameters name={{$:/SiteTitle}} age="21">
My name is <<name>> and my age is <<age>>.
</$parameters>
\end

<$transclude $variable="myproc" age="19"/>

I tried to include something along these lines in your code, but I couldn’t understand where <<eg>> variable came from in the first <%if>, so I didn’t succeed.

Hope this helps anyway.

Fred

[Springer]

@tw-FRed

I couldn’t understand where <<eg>> variable came from in the first <%if>, so I didn’t succeed.

Ha, I started explaining, and then decided to hammer through to a better version. I solved the currentTiddler variable (with parameter, as you suggested), as well as the apparent need for example-macro workaround, at the same time.

I’ve updated the code at my post above

[Springer]

I’ve submitted a GitHub feature request, based on the decently-compact code I worked out today.

In addition to defaulting to currentTiddler and using the cascade (for block mode translink), it detects simple recursion, and flags it with standard recursive transclusion alert.

I trust that if there are systemic reasons not to improve translink in this way, others will chime in. (Of course, it may still be far from top priority, and code may not be optimized.)

[TW_Tones]

@Springer such macros are usually designed to be called from within other contexts rather than used stand alone, not that that is not a valid use. For this reason I see value keeping the macro simple. When adding features that are all about the output it would make more sense having a new widget such as $translink widget. This could still call the underlying macro (if nessasary) but introduce the other customisability, especialy the UI elements, in part because widgets are typicaly where things go to be displayed (The exception is the outer of nesting).

• Changes could be applied to the translink macro with a view to supporing an advanced $translink widget, but in such a way there is no change in behaviour unless given additional attributes.
• This is a new approach to solutions made available with custom widgets and recent features.
• Exending and enhancing without core changes, that is by addition allows such a solution be packaged as a plugin and when mature adopted into the core.

[well-noted]

I also think a new widget might be the way to go – I think additional customizability would be especially helpful, rather than just relying on the cascade: in other words, I would want to have variations of my body templates for translink, which could have a unique tag or be added to a list, and tying it to the core translink macro is likely to always present limitations.

I do hope you’ll continue to work on this, @Springer, as it’s a very good idea and if it were to be comprehensively fleshed out it would become a staple of my process