Two-way linking: footnote of related tiddlers, issues, references

287 views
Skip to first unread message

bimlas

unread,
Nov 18, 2019, 2:02:29 AM11/18/19
to TiddlyWiki
In TiddlyWiki you can create direct links to a tiddler or list them according to a filter. However, there are times when it would be nice for a tiddler to automatically appear at all connected tiddlers without doing anything. Thus I created a two-way link "mechanism": instead of referring to the source, the source specifies which tiddlers it is linked to. This is useful when, for example, I want to remind myself of a possibility of error.

The easiest way to understand this is to look at a specific example: https://bimlas.gitlab.io/#Proper%20shebang%20line

This tiddler is about the correct form of the shebang line (needed for shell scripts). Since I'm not always going to remember this, I want to make sure that TiddlyWiki reminds me when I viewing a tiddler contains shell code, so I defined the conditions under which this information will be displayed (as a filter in "condition-to-show-in-footnote" field of this tiddler).

[search[#!/usr/bin/]]

So for those tiddlers that have the phrase "#!/usr/bin" in their text, I'd like to automatically see a link to the shebang note, thus I created a viewtemplate (attached as well) to display the link where this condition is met, and to list these target tiddlers for the shebang note.

With this solution, I only need to set up a filter once and a link to the source always appears at the bottom of the associated tiddlers.

Attention! Use a simple filter that doesn't take much time to execute, otherwise the wiki may become slow (for example, don't use the Kin filter).
$__bimlas_footnote-of-possible-issues_template.json

TonyM

unread,
Nov 18, 2019, 3:28:38 AM11/18/19
to TiddlyWiki
Bimlases

Thanks for sharing. I have done similar things before. One way to reduce the influence of complex filters is to only show the "related tiddlers" if a tiddler has a tag or field name toggled on. So just toggle on for relevant tiddlers, or toggle the whole system on or off.

The best solution is a global toggle you can override localy on each tiddler. I have some nice code for this if you want.

Regards
Tony

bimlas

unread,
Nov 18, 2019, 5:20:46 AM11/18/19
to TiddlyWiki
TonyM,

Please give me an example because I don't quite understand.

TonyM

unread,
Nov 18, 2019, 7:10:21 AM11/18/19
to TiddlyWiki
Quick dump more tomorrow

$:/config/relatedTiddlers
Contains show or hide

Macro tiddler
'
\define Related()
<$set name=result value={{!!relatedTiddlers}} emptyValue={{$:/config/relatedTiddlers}}>
<<result>>
</$set>
\end

In a tiddler or view template <<Related>> will return the global setting in $:/config/relatedTiddlers unless the field on the current tiddler relatedTiddlers overrides the global.

E.g.
<$list filter="[<showRelated>match[show]]" variable=nul>
Insert your code here to show
</$list>

then provide the ability to toggle the value show or hide in $:/config/relatedTiddlers or the field relatedTiddlers on the current tiddler including the ability to delete relatedTiddlers on the current tiddler to revert to global setting.

Does that make sense?

tony


bimlas

unread,
Nov 18, 2019, 7:19:19 AM11/18/19
to TiddlyWiki
Ok, I think I understand: So you list related tiddlers in a field, or if this field is empty you use a golbally defined list. I see some sense of it, but I created the solution above so that I don't have to refer to the source everywhere, but the source is automatically listed. Actually, usage will determine which solution to choose, so I think both have a reason to exist. :)

TonyM

unread,
Nov 18, 2019, 11:00:38 PM11/18/19
to TiddlyWiki
Bimlas,

No ! Not "list related tiddlers in a field"

My method would allow you to turn on or off the display of the related tiddlers that your solution provides to all or no tiddlers. However a local field can can be used to show or hide it on individual tiddlers as an override. I am only suggesting selective display of your solution on tiddlers. This allows ones that really do not need it to turn this off, and those on which its important to turn it on. And a quick way to add it or remove it from all tiddlers.

Regards
Tony

HC Haase

unread,
Nov 19, 2019, 7:04:00 AM11/19/19
to TiddlyWiki

This is interesting. It sounds like @bimlas and @tonyM could cook up a really nice feature!

I think this gives some nice opposites to see connection that was otherwise hidden. It could make some emergence in the system of knowledge (tiddlers).

could we discuss what this actually is? I am not quite sure.

In TW we have tags, links and backlinks as the main relation between tiddlers

tags
can be hierarchies as in the TOC, and more network oriented. it gives us categories

links
is a stronger relation that tags, it gives us a direct connection to another tiddler.

backlinks
are also links, but not as intentional as normal links, thus these could bring some emergence and show connection you forgot.

Two-way linking (forward linking)
This mechanism that you are making has the potential to link to the future so we could call it forward linking (future linking also sound cool). It makes a link that appear when a matching tiddler is made in the future (and also for existing ones), a potential linking. I think this has the potential for creating emergence and show connection that were not obvious to you.
BUT
how do this differ from tags? tags (it you explore them) also show relation between tiddlers from different points in time, and could also be used as link to future potential tiddlers. However the forward linking makes this explicit without any user action.
How do this differ from a search? as I understand, the filter that you define is the same as a search, right? So you could say that this provides a communication, where pas you can make a search for future you (wow time travel).

I have the feeling that this could be something more than tags and search, but I am not quite sure. I think there is some interesting potential here.

any way, what are your thoughts in this direction?

HC Haase

unread,
Nov 19, 2019, 7:07:51 AM11/19/19
to TiddlyWiki

Attention! Use a simple filter that doesn't take much time to execute, otherwise the wiki may become slow (for example, don't use the Kin filter).

Does this mean that it is performance heavy? what if you were to us this with simple filters extensively in many tiddlers, would this take a hit on performance? (thinking especially of TW running on a phone).

Do you think performance could be optimised some how? what about using the indexed filters in search, or is that irrelevant here?

TiddlyTweeter

unread,
Nov 19, 2019, 3:00:19 PM11/19/19
to TiddlyWiki
I have not had time to try this yet.

Bimlas, when you say "two way linking" do you mean that I could click a link in a wiki, to say a footnote, go to it and THEN click the visited footnote to RETURN to exactly where the link is I navigated to the footnote from originally? The point being having reciprocal linking. If so: GREAT.

In TW, of course, the issue is most of the "page" is not visible unless explicitly invoked.

Just asking
TT

bimlas

unread,
Nov 19, 2019, 5:19:05 PM11/19/19
to TiddlyWiki
TonyM,
 
My method would allow you to turn on or off the display of the related tiddlers that your solution provides to all or no tiddlers.

Ok, now I understand what you mean.

I like the basic idea because it would speed up wiki, but the point of the solution is to make sure that the tiddlers that match the filter showing the related tiddler link, because it is in some way related to what is currently displayed. (I hope Translator translates well what I mean :D) So if for example (as in the opening post) I have a tiddler about the correct format of the shebang line of a shell script then a link to this should be visible when I read a note about a specific shell script.

While writing this, I recalled when I use this two-way link: when I create a tiddler for a new experience (like a shell script I found on the Internet), saving it, the appearing link to the shebang at the bottom reminds me to check the first line of the new shell script. So, first of all, it serves as a kind of warning. In such cases, it would be almost better to have the link appear in edit mode, but when reading the wiki, it could be disabled as your solution does.

On the other hand, there are times when I constantly want the link to appear because it reminds me of something that is not an integral part of the currently read tiddler, but is closely related to it. For example, the description of the Timimi plugin is closely related to the Download Saver + unique Firefox profile solution, but the latter is not about Timimi, so I just want to list a link. Although I could create a link within the text, but with this "forward link" (as HC Haase put it) I can automatically link the Firefox solution to any other save options. In these cases, I would not want to hide the link.

And by the end, I think I now fully understand what you are saying. So, for example, if I have a Timimi tiddler that contains a shell script as well, I could set up a "blacklisted related tiddlers" field in this (contains title of the shebang line tiddler), so that these (shebang line) would be not listed? I think this seems like a good idea and it really speeds up the things.

To be honest, the global disable option does not make sense because I need to remember to see if there is a related tiddler, even though their purpose is to remind me by their own.

bimlas

unread,
Nov 19, 2019, 5:36:28 PM11/19/19
to TiddlyWiki
HC Haase,
 
Two-way linking (forward linking)

Let's call it "conditional linking", btw "future linking" seems right as well. :) Maybe "conditional tagging" (see bellow).
 
how do this differ from tags? tags (it you explore them) also show relation between tiddlers from different points in time ...

It's right.
 
... and could also be used as link to future potential tiddlers.

In fact, the tag does not link to the potential tiddler, but on the contrary, the tiddler indicates that he belongs to this tag. So in the tiddler you have to determine which "groups" it belongs to. Conditional linking, on the other hand, is created on the basis of a filter, a group of tiddlers meeting the same criteria. When it comes to comparing with a tag, conditional linking is a tag that determines who belongs to it.
 
How do this differ from a search? as I understand, the filter that you define is the same as a search, right?

Yep. I've used exactly searching expression, but you can use whatever filter you want ([tag[x]custom-field[y]...]).
 
any way, what are your thoughts in this direction?

Originally, I didn't have any goals with this solution, I just wanted to publish it, but it seems that more people are interested in it, so it's worth developing. 

bimlas

unread,
Nov 19, 2019, 5:45:00 PM11/19/19
to TiddlyWiki
TiddlyTweeter, 

I could click a link in a wiki, to say a footnote, go to it and THEN click the visited footnote to RETURN to exactly where the link is I navigated to the footnote from originally?

I'm not sure I understand your question, so here's a concrete example:


The "Proper shebang line" tiddler has a "condition-to-show-in-footnote" field, which contains the "[search[#!/usr/bin/]]" filter, so for those tiddlers, where the search term is found ("Command line arguments parser in Python" for example), a link to the "proper shebang line" tiddler appears in the footnote. The footnote of the "Proper shebang line" lists which tiddlers appear (so simply the output of the filter).

bimlas

unread,
Nov 19, 2019, 5:53:34 PM11/19/19
to TiddlyWiki
HC Haase,

 
Does this mean that it is performance heavy? what if you were to us this with simple filters extensively in many tiddlers, would this take a hit on performance?

Performance depends on two things:

- How many tiddlers are open? 
- How many tiddlers are given this special field?
- How long do the specified filters take?

The more the slower. I have to try (but not now) what happens if, for example, only one tiddler is open but 100 have the same filter in the field (for example "[search [a]]"). If I guess, the wiki will slow down. If it does not slow down, only the number of opened tiddlers and the complexity of the filters will affect the performance.

Do you think performance could be optimised some how?

See the discussion with TonyM.
 
what about using the indexed filters in search, or is that irrelevant here?

It is up to the filter to use this feature. 

bimlas

unread,
Nov 20, 2019, 3:35:54 AM11/20/19
to TiddlyWiki
TonyM,

The code is still far from perfect (I don't have much time to refactor, but I will do it soon), but I think that's what you meant (attached): https://bimlas.gitlab.io/#Proper%20shebang%20line

Open one of the related tiddlers and see the footnote.


$__bimlas_footnote-of-possible-issues_template.json

bimlas

unread,
Nov 20, 2019, 4:01:32 AM11/20/19
to TiddlyWiki
More specifically, this is not exactly what you were thinking, but serves a similar purpose.

bimlas

unread,
Nov 20, 2019, 8:02:30 AM11/20/19
to TiddlyWiki
HC Haase,


I have to try (but not now) what happens if, for example, only one tiddler is open but 100 have the same filter in the field (for example "[search [a]]"). If I guess, the wiki will slow down. If it does not slow down, only the number of opened tiddlers and the complexity of the filters will affect the performance.

Reply all
Reply to author
Forward
0 new messages