Presenting: AliasTids - one tiddler, many titles

[Mat]

From the crypts, Mr von TWaddle has burned up yet a few brain cells for the benefit of his fellow tiddleurs...

...and thus proudly presents....

AliasTids

This is a new approach to aliases with the main benefit that it is very simple

to use and it doesn't distract your writing: Just type links like normal!

<:-)

[TonyM]

Mat,

Nice idea. If such alias names for tiddlers where searchable like regular titles this could be revolutionary. I imagine the caption field would benefit from such a feature as well.

 

Regards

Tony

There is a small issue which is not part of the main functionality. You can see it

in the bonus tiddler AliasesOverview. I'm announcing this thing anyway

hoping  that some friendly soul can help out with that issue.

<:-)

[h0p3]

Awesome work, thank you. Aliasing is an important part of my wiki, but I can't say I understand the issues well enough. Does your tool differ in a crucial respect from https://mklauber.github.io/tw5-plugins/#Aliases ? I am also on the hunt for aliasing which works with search, and which is lightweight enough to not freeze out linked-to referencing from tiddler info.

[Mohammad]

Great job Mat!

Mario has also an alias plugin!

My suggestion is: as previously discussed here by others, it would be great if the core can implement tiddlers to have unique ID to be addressed with many names!

(effors have been made and plugins are available but nothing in the core)

-Mohammad

[PMario]

Hi Mat,

Nice work. ... Seems to be similar to my uni-link plugin [1]. ...

One main problem, for me, with aliases was, that I also want to have the "alias-backlink" info in the info panel.

There is a short video [2], which shows all the functions. uni-link plugin also implements some filter operators, that help with alias handling.

• is[alias], all[aliases], [aliasbacklinks[]],  [[?]aliasbacklinks[]sort[title]]

have fun!

mario

[1] https://wikilabs.github.io/editions/uni-link/

[2] https://youtu.be/IelDdM7iXrA

[PMario]

On Tuesday, July 2, 2019 at 6:04:25 AM UTC+2, Mohammad wrote:

...

My suggestion is: as previously discussed here by others, it would be great if the core can implement tiddlers to have unique ID to be addressed with many names!

(effors have been made and plugins are available but nothing in the core)

Tiddlers have a human readable unique ID. .. The title field. ...

There's no need to create a human un-friendly ID.

-m

[TonyM]

Mario,

There's no need to create a human un-friendly ID. 

There is if you establish relationships to other tiddlers based on the title then rename it. 

• The problem with title is it may be always unique, but it can change. So is something really unique if does not remain the same over time?
• An example is using the Qualify macro to set states

For this reoccurring issue I built a simple way of creating a unique ID but it needs to be button driven and thus requires user intervention to stamp a tiddler.

1. Take the current tiddlers full serial created date
2. Check if it is unique, 
1. if not add 1 microsecond re do step 2
2. If unique set the field unique-id to the fullserial+N
3. Use the contents of unique-id when ever you want to link something to the current tiddler
4. We could have a qualify macro that uses the unique-ID to do so. 

This just needs to be made into a javascript and placed into the core create tiddler with a toggle to switch it on. No need to retrofit tiddlers already created, but easy with a button.

If no one else does this I will eventually out of frustration, need to finish my javascript and tiddlywiki dev learnings.

Regards

Tony

[Mat]

h0p3 wrote:

Does your tool differ in a crucial respect from https://mklauber.github.io/tw5-plugins/#Aliases ?

G'dang! I hadn't looked at mklaubers plugin. It does seem very similar... and possibly even better, in that clicking an alias navigates to the real tiddler. My version shows the content of the real tiddler but uses the alias name. I can see how mklaubers variant is better for mentally fostering the user to remember the original titles.

I must investigate if I should simply deprecate my variant.

<:-)

[Mat]

TonyM wrote:

Nice idea. If such alias names for tiddlers where searchable like regular titles this could be revolutionary. I imagine the caption field would benefit from such a feature as well.

You say "searchable like regular titles" but IMO if you type in an alias name the search results should probably only show the real tiddler as a result. If you type in some content (from the original tiddler), the alias names should probably not show up .

Tobias has crated http://tobibeer.github.io/tb5/#%24%3A%2F.tb%2Fui%2FAdvancedSearch%2FField which adds a tab to the advanced search, for searching in fields.

<:-)

[BurningTreeC]

Hi Mat,

this is a really simple but GREAT solution :)

I think the core could really profit from one of all the solutions out there. Maybe a good mix?

Yours is very simple and I like that, thank you for your work!

Simon

[Mohammad]

No, I think these are great stuff and help people to learn different approach!

So, please keep it! I like your simple solution too!

--Mohammad

[Mat]

PMario wrote:

Nice work. ... Seems to be similar to my uni-link plugin [1]. ... 

Yes, I was inspired by your plugin :-)

I like the integration with the caption field. 

 

One main problem, for me, with aliases was, that I also want to have the "alias-backlink" info in the info panel. 

What exactly is the problem?

 

There is a short video [2], which shows all the functions. uni-link plugin also implements some filter operators, that help with alias handling.

• is[alias], all[aliases], [aliasbacklinks[]],  [[?]aliasbacklinks[]sort[title]]

What "is" an alias in your solution. Is it a non-existing tiddler whose title title appear in any other tiddlers 'aliases' field?

<:-)

[Mat]

BurningTreeC wrote:

I think the core could really profit from one of all the solutions out there. Maybe a good mix?

Yes, IMO the core does need some aliases solution. It is actually surprising it's not there given how universal this need has always been.

<:-)

[Mat]

Mohammad wrote:

No, I think these are great stuff and help people to learn different approach!

So, please keep it! I like your simple solution too!

Thanks. I do note that mklaubers solution is js based whereas mine is wikitext which I see as an advantage for hackability (...because I don't know js and a user shouldn't have to of course).

<:-)

[TonyM]

I agree on the need for aliases but the caption field satisfies part of the issue, like friendlier names, perhaps that's why we still need to use macros or plugins to address this. Just saying.

Since tiddlywiki handles tiddler titles in many ways people's expectations can be quite high to get the same features with any alias system.

Regards

Tony

[PMario]

On Tuesday, July 2, 2019 at 1:23:56 PM UTC+2, TonyM wrote:

...

Since tiddlywiki handles tiddler titles in many ways people's expectations can be quite high to get the same features with any alias system.

I think that's the point. ... You basically need to be able to do all things in the same way as you do with titles atm.

Accessing the tiddler store using a title is a single lookup function, which is as fast as the browser memory management can make it.

Accessing an alias name needs to iterate over every tiddler in the store and have a look at the aliases field, if the alias is there.

Worst case: The last tiddler contains the wanted alias. :/

Best case: The first tiddler contains the alias. ... In average that's slower as directly accessing a title.

plugins can use a caching mechanism. So only the first lookup will be slower.

In TW 5.1.20 Jeremy introduces an indexing system, that can speed up filter operations. ... I'll definitely experiment with this new functionality with the uni-link plugin and aliases. .. The second test should be done with 60.000 tiddlers as Jeremy mentioned in the pull request.

-m

[Mat]

PMario wrote:

Accessing an alias name needs to iterate over every tiddler in the store and have a look at the aliases field, if the alias is there. 

Worst case: The last tiddler contains the wanted alias. :/

Best case: The first tiddler contains the alias. ... In average that's slower as directly accessing a title.

Don't all tiddlers still have to be searched even if you hit that best case? Or how do you "cut" a filter search? My impression is that every filter is run "in full".

 

plugins can use a caching mechanism. So only the first lookup will be slower. 

Could this theoretically be "brought to the front" so users could state "chache this"... maybe even as part of Jermys new "kill the magic black boxes" ambition?

<:-)

[Ste Wilson]

Only tangentially related but the tiddlymap plugin creates a unique id field for each toddler...

[Ste Wilson]

And more on track skeeves has the following for alias. http://tw5magick.tiddlyspot.com/

\define find_original()
<$list filter="[field:alias/\|$(the_alias)$\|/(i)sort[title]limit[1]]"><$link>{{$(the_alias)$||unwikified}}</$link></$list>
\end

<$set name="the_alias" value={{!!title}}><<find_original>></$set>

[Mat]

I'm guessing you're talking to me.

Is that a regexp or what's with the escapes? 

If the point is to get all tids that have a certain value in their alias field, then I think the contains operator should probably be used which I believe was added after skeeve made that code.

<:-)

[PMario]

On Wednesday, July 3, 2019 at 1:47:26 AM UTC+2, Mat wrote:

PMario wrote:

Accessing an alias name needs to iterate over every tiddler in the store and have a look at the aliases field, if the alias is there. 

Worst case: The last tiddler contains the wanted alias. :/

Best case: The first tiddler contains the alias. ... In average that's slower as directly accessing a title.

Don't all tiddlers still have to be searched even if you hit that best case? Or how do you "cut" a filter search? My impression is that every filter is run "in full".

Uups. you are right. If 2 aliases contain the same value. Both of them are shown. .. Worst case all the time :/ ... That's why indexing should be able to help us here. ... But only tests will show :)

 

 

plugins can use a caching mechanism. So only the first lookup will be slower. 

Could this theoretically be "brought to the front" so users could state "chache this"... maybe even as part of Jermys new "kill the magic black boxes" ambition?

Not really. ... The new "tag" and "field" indexes, are created automatically from the core. There is some javascript involved. I don't think we can make those options "user facing", since you need deep knowledge of the internal "store structure". And you'll probably always need specialized code.

-m

[Mat]

Update

I've updated the AliasesOverview, i.e the "aliases manager" area. It now works well and I'm overall pretty happy with the layout of it.

<:-)

[Mohammad]

Mat,

 I recommend to use a link to code/demo page in any posts announce new change / update!

Cheers

Mohammad