[TW5] preventing tiddler-links to break by using ids as reference that translate into titles

[Felix Küppers]

Hello,

I am currently working on my master thesis and organize myself via TW5.

TW5 is truly a great program and it really supports my workflow, however I have a little problem.

My problem:

Structuring new thoughts is always a difficult process and consequently,
I often rename the titles of the tiddlers, because I feel that a title became inappropriate or contains an error.

This usually breaks all my links that reference the topic with the changed title.
Never changing a title after it has been introduced is not a suitable solution for me.

Masking the referencing links as in [[masked title|orignal title] doesn't help, as it is
cumbersome and does not solve the problem of the wrong original title.

Another bad solution (wikipedia-style): Creating a new tiddler with the corrected title that transcludes
the tiddler with the old title and link to the new tiddler from now on.

My solution so far:

My solution to the problem would be to create tiddlers with a unique ID field which can be
referenced via [[ id ]] and translates to the title of the tiddler. the id is never
changed and serves as a proxy (as in SQL automatically generated primary keys).

For now, I create an ID-field with a custom newtiddler button that generates a unique key
via

Math.random().toString(36).substr(2, 9);

and I reference a tiddler with this id via the following "link"

<$list filter=[field:id[qqu99yie1]!has[draft.of]] />

As this link code is hard to write everytime I want a reference, I added a link-info-button
into each tiddlers heading, that produces the link-code when I click it.
















Now everytime a change to the tiddler's title occurs, I don't have to modify any references.

My question:

Could a mechanism like this be integrated into TW5? This means:

1) adding a unique id automatically to each new tiddler.
2) linking to an article via [[ id ]] which translates into its title.

Or has this issue been solved otherwise? Maybe I am missing something...

[Danielo Rodríguez]

Why don't you use

 {{{ [field:id[qqu99yie1]!has[draft.of]] }}}

instead of 

<$list filter=[field:id[qqu99yie1]!has[draft.of]] />

It's shorter and easier

[Stephan Hradek]

If you only use explicit links, why not check which tiddlers reference the one you're renaming and fix the links there first?

[Stephan Hradek]

P.S. Maybe Aliases will help you?

http://tw5magick.tiddlyspot.com/ search for "Aliases".

[Felix Küppers]

Hi Stephan,

I checked out your alias system, it's a nice way if I want to provide alternative names but this is not the case for me.
I don't want to create tags that contain titles just because I changed the original title.
Wikipedia uses aliases to redirect to changed titles, but I don't like this approach as this would mess up my wiki.

Changing the referencing links first before changing a title is, as I said above, to cumbersome.

...

Well, if there does not exist any integrated TW5-solution for proxy-references via ids, I guess I have to stick to
my own solution. Maybe this feature is introduced in a future TW version, as I think it is quite useful and does not break
any existing mechanism.

[Stephan Hradek]

I can't see a fundamental difference between my alias approach and using IDs. Except that ID's tend to be unreadable.

[Felix Küppers]

Well, I know linking via ids is not readable in edit mode, however in a non-edit mode, the id translates to a name, so that is ok for me.

As for semantic-alias (i.e. a real second title) vs. ids, I rather chose ids as their purpose is only to allow exact references. same as in SQL autoincrement primary keys...
And I rather place them inside a field because I like them to be more "invisible" as they have no semantic meaning.

However I took a closer look at you example in your space and it is a really nice workaround you are using, I mean exploiting the masking-title of the link as a variable to use it in a local macro.

This way I could do something like

{{ 415241 | id }}

and put the filter in the macro instead of directly writing

{{{ [field:id[]!has[draft.of]first[]] }}}

that will make a nice shortcut...

[Jeremy Ruston]

This question of whether tiddlers should be identified by title or by an abstract GUID is a perennial one.

My aim is that users should be able to use GUIDs for tiddler titles if it suits their use case. The missing piece is a way of linking to a tiddler by it's GUID/title, but having a specified field displayed as the text of the link. Here's an example of a macro to do that:

\define link(guid)

<$tiddler tiddler="$guid$"><$link><$view field="name"/></$link></$tiddler>

\end

This is a link by guid <<link qqu99yie1>>

Of course, it would be more useful if one could arrange for that macro to be automatically substituted for links.

Best wishes

Jeremy.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

--
Jeremy Ruston
mailto:jeremy...@gmail.com

[Felix Küppers]

Hi Jeremy,

I don't want to abolish titles replacing them entirely with mere ids :)
I only want to link via ids so nothing breaks when I change any title.

Therefore I will use a field to store a tiddler's id.

Making use of Stephan's suggestion I can now write {{ qqu99yie1 | id }}. So I am quite satisfied for now.

However, thanks for pointing out the option to use the link and the view widget together to be able to chose an alternate name based on a field-value, that might come one handy at one point.

By the way, is there any reason, why the tiddlers do not get a unique id on creation time as a field value per default?
This would support people to create unbreakable references via ids, without the previous effort to give each tiddler a unique id or creating a custom button.

Regards
Felix

[Jeremy Ruston]

Hi Felix

By the way, is there any reason, why the tiddlers do not get a unique id on creation time as a field value per default?
This would support people to create unbreakable references via ids, without the previous effort to give each tiddler a unique id or creating a custom button.

That's the unavoidable, perennial question referred to above. A simple formulation is: do we use the "title" field as the identifier for a tiddler the "title" field, or do we use a separate "ID" field. The two options can't co-exist, we need to choose one. TiddlyWiki chooses the former on the basis that is a more human formulation, and that it can trivially emulate the ID approach. But that is done by using the title field as an ID, not by introducing a new ID field. The reason is because of the need to enforce uniqueness: we guarantee the uniqueness of titles, but not of other fields.

Best wishes

Jeremy.

[Felix Küppers]

Hi Jeremy,

thank you for this clarification. I understand and support your deliberate choice in this matter.
I am new to TW and my overall understanding is still developing :)

That said, I apologize for bothering you with my newbie-opinions or questions, but from my understanding
it is possible to have more than one unique-field that identifies a tiddler. Similar to SQL
where I can have several unique attributes in a table that each could be used to identify a row.
If a new tiddler is created, the system only needs to ensure that the title AND the id is unique.

From this point on, it is the decision of the user to reference the tiddler by id or by title.
As written above, I have introduced this mechanism in my wiki and it works well.

Providing a build-in alternative to a reference-by-title concept for those who want it would be a nice
feature because links wouldn't break. Maybe it's not a common issue but I found a threat on stackexchange
where a user had the same problem:
http://webapps.stackexchange.com/questions/22850/changing-the-name-of-a-tiddler-in-tiddlywiki-and-retain-the-references-pointing

In any case, I fully support your choice to use the title as unique identifier and if TW internals
do not allow the introduction of such a parallel-concept then it is totally fine. I think TW is
great and offers much flexibility either way!

So thank you for your work and your previous answers.

Greetings
Felix

[Matabele]

Hi

One of the disadvantages of using the 'title' field as the unique ID is, for example, the impossibility of having more than one tiddler with the title 'Introduction'. If I wish to use a single TW for several articles/books, each of which has an introduction -- I am forced to use titles such as 'Article1 - Introduction' and 'Article2 - Introduction'. Further, in the finished articles, I must then use labelled links such as [[Introduction|Article1 - Introduction]], if I want the section to be titled 'Introduction'.

This makes a strong case for the use of unique uuid's for linking to tiddlers, with the 'title' field as an alias for the link to the tiddler.

A possible mechanism: 

1. a unique ID for the tiddler is created when a new tiddler is first saved, and

2. an addition is made to a dictionary mapping the new 'title' field to the ID

3. when a title is edited, a new entry is added to the dictionary (but the old one remains)

4. the tiddler can now be linked via the ID, the old title or the new title

5. any additional aliases may be added to the dictionary for the same ID

The problem here: that using the alias 'Introduction' will now link to several ID's -- how do I specify which of the tiddlers with the alias 'Introduction' I wish to target?

My first thought on this is to use two 'anded' aliases to link to a particular tiddler, when a single alias refers to several tiddler ID's -- [[Introduction && Article1]]. Now, this will pick the correct tiddler, and the displayed title will be whatever the current title of that tiddler -- in this case 'Introduction' -- which is my desired behaviour. The whole scheme is beginning to look rather like tags!

Have no idea how difficult this would be to implement -- just an opinion from an end-user point of view.

regards

 

On Monday, June 2, 2014 6:46:26 PM UTC+2, Jeremy Ruston wrote:

Hi Felix

[Jeremy Ruston]

Hi Felix

That said, I apologize for bothering you with my newbie-opinions or questions, but from my understanding
it is possible to have more than one unique-field that identifies a tiddler. Similar to SQL
where I can have several unique attributes in a table that each could be used to identify a row.
If a new tiddler is created, the system only needs to ensure that the title AND the id is unique.

To have two unique tiddler fields in JavaScript would mean using a separate hashmap for each field that we want to enforce uniqueness. It would considerably complicate all the low level operations involving tiddlers. Right now, TW can be fast because the tiddler store is a very thin wrapper around JavaScript's native storage mechanisms.

 

From this point on, it is the decision of the user to reference the tiddler by id or by title.
As written above, I have introduced this mechanism in my wiki and it works well.

The bit that you don't have is enforcement of the uniqueness of the ID, though. One could imagine adding tools that prompt you if you've got an ID clash, and that wouldn't be ridiculously expensive. But making it a properly enforced constraint is expensive.

 

Providing a build-in alternative to a reference-by-title concept for those who want it would be a nice
feature because links wouldn't break. Maybe it's not a common issue but I found a threat on stackexchange
where a user had the same problem:
http://webapps.stackexchange.com/questions/22850/changing-the-name-of-a-tiddler-in-tiddlywiki-and-retain-the-references-pointing

Link breakage is definitely a common problem. As I said at the top, I'm keen to support the ID way of working as an option (using the title field as the ID), but I don't think it's practical to enforce multiple unique fields on the tiddler store.

My preferred solution to the breaking links problem is also a solution to wider problems of wikitext authorship: a decent search and replace operation that is syntactically aware; it can reliably find and replace all the references to a tiddler (without being confused by plain text references to the same text).

 

In any case, I fully support your choice to use the title as unique identifier and if TW internals
do not allow the introduction of such a parallel-concept then it is totally fine. I think TW is
great and offers much flexibility either way!

So thank you for your work and your previous answers.

Sorry for labouring the response to your points; I just figured it may be useful to lay out some of the reasoning.

Best wishes

Jeremy

[Felix Küppers]

Hi Jeremy,

To have two unique tiddler fields in JavaScript would mean using a separate hashmap for each field that we want to enforce uniqueness. It would considerably complicate all the low level operations involving tiddlers. Right now, TW can be fast because the tiddler store is a very thin wrapper around JavaScript's native storage mechanisms.

I already figured that there would be some performance drawbacks or complexity-issues when using ids as a parallel mechanism, however, thanks for explicitly highlighting this point.

The bit that you don't have is enforcement of the uniqueness of the ID, though.

That is true, I pray to god that the javascript function never creates the same id twice.

My preferred solution to the breaking links problem is also a solution to wider problems of wikitext authorship: a decent search and replace operation that is syntactically aware; it can reliably find and replace all the references to a tiddler (without being confused by plain text references to the same text).

That would be a nice solution, similiar to refactoring-dialogs in modern IDEs, however, this is also extremely complicated to program as the issue becomes quite complex.

Sorry for labouring the response to your points; I just figured it may be useful to lay out some of the reasoning.

That's ok. :) I regard my original question as answered.

Regards
Felix

[Stephan Hradek]

Am Dienstag, 3. Juni 2014 12:51:04 UTC+2 schrieb Felix Küppers:

That is true, I pray to god that the javascript function never creates the same id twice.

http://tiddlystuff.tiddlyspot.com/ -> UUIDmacro

[Felix Küppers]

Hi Danielo,
thanks for your hint, I didn't know this syntax exists, I will certainly use it.

[Brady77]

Hi,

any solution to the problem? I don't believe that Felix and me are the only TiddlyWiki users who are struggling with renaming the tiddlers (or tags). Let's go to the roots of TiddlyWiki that positions as a system of small pieces of related information. How does is play with such a basic operation called "change tiddler title" by breaking all references? There is probably something I have missed at the beginning but it seems to me like building a dam on a river from sugar cubes: you have a solid structure just until you fill it with water...

Is it a technical problem? Or a too much work to change the system? Or a backward compatibility problem? A combination of? Should we create a plan to untangle it? 

[PMario]

This is a really old topic. .. TW has changed quite a bit ...

On Tuesday, April 17, 2018 at 1:01:47 PM UTC+2, Brady77 wrote:

Hi,

any solution to the problem?

partially. .. I think it can be solved with plugins now. ... My unilink plugin may be an option.
 

I don't believe that Felix and me are the only TiddlyWiki users who are struggling with renaming the tiddlers (or tags).

TiddlyWiki contains a new mechanism now, that "batch renames" all existing tags, if you rename a tiddler title. .. So if you change a tag-tiddler the core will do the batch processing.

This doesn't change links like: [[tag-name-here]] in tiddler text. ... But if you rename your tiddlers a lot you will have a lot of [[prettylinks|tag-name-tiddler]] anyway. Otherwise your text will be hard to read. ... The alias-plugin, which is part of uni-link will help your here. -> No renaming needed!
 

Let's go to the roots of TiddlyWiki that positions as a system of small pieces of related information. How does is play with such a basic operation called "change tiddler title" by breaking all references? There is probably something I have missed at the beginning but it seems to me like building a dam on a river from sugar cubes: you have a solid structure just until you fill it with water...

There are many users, where the existing mechanism works well, for a really long time. ...

I know, that naming tiddlers is hard! .. That's why I use uni-link ;) and a theme, that doesn't use tiddler titles as a heading. see: https://wikilabs.github.io/editions/slant-01/  My tiddler names look like: this-is-a-tiddler-name, which I don't change anymore. ...

I use "real headings" at the tiddler body, which allows me to use the tiddler title as an "index" and I can change the heading as often as I want. "caption" and "subtitle" are very handy here.

This works well with the above mentioned plugins, which don't break TWs, that don't use the plugins, if you copy your texts. (but the functionality will be different!)
 

Is it a technical problem?

Partially yes. The whole core javascript code and UI uses the tiddler title as a heading. .... because it's easy for new users.
 

Or a too much work to change the system?

Yes. ... If you really want to have it in a different way, without regressions in functionality, you better start from scratch. It would be much less work.
 

Or a backward compatibility problem?

A combination of?

Yes. ...
 

Should we create a plan to untangle it? 

IMO it's a plugin- and not a core-problem.

have fun!
mario

[Brady77]

 

 

Hi,

any solution to the problem?

partially. .. I think it can be solved with plugins now. ... My unilink plugin may be an option.

Please can you elaborate on "partially"? What areas of the TiddlyWiki are not covered by using your Unilink plugin?

 

 

I don't believe that Felix and me are the only TiddlyWiki users who are struggling with renaming the tiddlers (or tags).

TiddlyWiki contains a new mechanism now, that "batch renames" all existing tags, if you rename a tiddler title. .. So if you change a tag-tiddler the core will do the batch processing.

This doesn't change links like: [[tag-name-here]] in tiddler text. ... But if you rename your tiddlers a lot you will have a lot of [[prettylinks|tag-name-tiddler]] anyway. Otherwise your text will be hard to read. ... The alias-plugin, which is part of uni-link will help your here. -> No renaming needed!

I'm confused here. What is the difference in renaming the tiddler or the tag? Tag is just a label, isn't is? So changing it should be super simple = there are no links...

 

 

Let's go to the roots of TiddlyWiki that positions as a system of small pieces of related information. How does is play with such a basic operation called "change tiddler title" by breaking all references? There is probably something I have missed at the beginning but it seems to me like building a dam on a river from sugar cubes: you have a solid structure just until you fill it with water...

There are many users, where the existing mechanism works well, for a really long time. ...

I know, that naming tiddlers is hard! .. That's why I use uni-link ;) and a theme, that doesn't use tiddler titles as a heading. see: https://wikilabs.github.io/editions/slant-01/  My tiddler names look like: this-is-a-tiddler-name, which I don't change anymore. ...

I use "real headings" at the tiddler body, which allows me to use the tiddler title as an "index" and I can change the heading as often as I want. "caption" and "subtitle" are very handy here.

This works well with the above mentioned plugins, which don't break TWs, that don't use the plugins, if you copy your texts. (but the functionality will be different!)

 

So you implemented something what Jeremy suggested in this thread above: "...users should be able to use GUIDs for tiddler titles if it suits their use case. The missing piece is a way of linking to a tiddler by it's GUID/title, but having a specified field displayed as the text of the link.". This is exact opposite to what Felix'es suggests by using "IDs" for GUIDs. 

 

 

Is it a technical problem?

Partially yes. The whole core javascript code and UI uses the tiddler title as a heading. .... because it's easy for new users.

Well, I am new to TiddlyWiki. After few edits to my Wiki I ended with an error: "Missing tiddler "XYZ" – click to create". I cannot agree that it is something what makes new users life easier. I thought I have a centrally managed system in one HTML file that encourages me to create many tiddlers to be connected by links. What I have now is a copy of world wide web system in my PC: a mess of 404 error links where only Google robots have the power to get some relevant data out of it. TiddlyWiki = big data?

 

 

Or a too much work to change the system?

Yes. ... If you really want to have it in a different way, without regressions in functionality, you better start from scratch. It would be much less work.
 

Or a backward compatibility problem?

A combination of?

Yes. ...
 

Should we create a plan to untangle it? 

IMO it's a plugin- and not a core-problem.

This is a core problem for sure. Tiddler should be an object with an internal ID. Just like in any document database (or NoSQL database). You can add fields to it with values but the object doesn't change it's identity by changing a field value. 

 

have fun!
mario

Thanks Mario for your informative response.  

[Jed Carty]

A tiddler is an object with an internal id, it is the title field. You can add fields to it without changing the identity of the tiddler. Once you change the title of the tiddler you are changing the internal id.

This same argument has been made many times and there has never been a solution presented that doesn't have the same problems as using a title. You need to have a unique identifier on each tiddler, to link to a tiddler you need this id. Regardless of how you twist things around this id is equivalent to the title. I think that in most cases it is much more convenient to have this id be a human readable one.

[@TiddlyTweeter]

I totally agree with Jed.

IMO, if normal titling is becoming an issue to (ID) organise what you need, then a first step is to step back and consider the design architecture of what you wanting to do. The problem with other work-arounds is it adds complications and overheads.

FWIW, to deal with this issue I adopted two different approaches ...

(1) where I need a clear ID I use the title field purely as the data-reference (e.g. Title-1_sub-7 etc) and the caption field for what is displayed. That is easy & reliable.

(2) where I want to use the title field only, that is displayed, I think through a schema of naming that is nor overly laborious. Its not always optimal--but mostly it is.

Best wishes
Josiah

[Brady77]

A tiddler is an object with an internal id, it is the title field. You can add fields to it without changing the identity of the tiddler. Once you change the title of the tiddler you are changing the internal id.

This same argument has been made many times and there has never been a solution presented that doesn't have the same problems as using a title. You need to have a unique identifier on each tiddler, to link to a tiddler you need this id. Regardless of how you twist things around this id is equivalent to the title. I think that in most cases it is much more convenient to have this id be a human readable one.

Thanks Jed for your opinion. I think that the internal ID is nothing a user is allowed to modify. This should be completely hidden from user interface. This is actually my only problem: I changed the internal ID of an object but it wasn't my intention at all. I just wanted to edit a text field and ended with broken links.

[Brady77]

Hi Josiah,

I appreciate your willingness to help. Let's say I will generate some unique ID for tiddler title. Next I use the "caption" field to as a real tiddler title. Could you tell me what files to change so I can use it as you suggest? I'm afraid that current tiddler title is hardcoded in many places. I'm also awaiting Mario's reply regarding the "partial" solution by using the "caption" field.

Petr

[Mark S.]

With all the talk about esoteric concepts like "Quines", I was surprised that TW5 had the same fundamental problem  that TWC had. In database parlance, you never use the same field for more than one thing. This is law #1 of database normalization, which allows for massive amounts of data to be processed every day even by relatively low-powered computers.

The title field is being used for at least 3 jobs: title, ID, and system flag. There should be 3 fields for each of these tasks. A beginner error is to then use it for something else (like dates).

The fix is to use something like uni-links so that the title field can be used as an immutable ID field. Another fix would be a tool that, when you change a title, finds and replaces all links. I thought there was a promise of such a thing a long time ago.

My general formulation for unique titles is

<date> <topic> [<user>]

The mistake would be, of course to use the title to *store* the date. I'm just using it here to keep things unique without having to think too hard.

Beginners using TW and used to full-fledged Wikis and other systems (Zim? Wikidpad?) will probably be surprised when changing titles doesn't also change links.

-- Mark

[Mark S.]

2014. I wonder if TW proved useful for Felix's master thesis project?

-- Mark

[Mark S.]

If you're using the uni-link plugin, it will automatically change how your links are rendered to match either the caption or the subtitle of the linked tiddler. You can then leave the tiddler alone, never renaming it but only changing "caption" or "subtitle" if you want to change how it looks when linked.

Basically, it allows you to use the title as a true immutable ID, and the caption or subtitle as the title. But it enables better performance -- it doesn't guarantee it. It's a partial solution because it doesn't fix existing broken links. You will have to find and fix them. There's also nothing to prevent you from forgetting and changing a tiddler title. The title of the tiddler that appears will be different than the title someone clicked on. Perhaps the ViewTemplate could be modified to also use the caption or subtitle, reducing confusion.

-- Mark

[@TiddlyTweeter]

Brady77 wrote:

I appreciate your willingness to help.

Mark S. just wrote a good reply that I think sums up a practical way forward for your situation (as far as I understand it). PMario's uni-link plugin adds a small overhead on performance. But its good for situations like yours. I mean, you don't want to backtrack now to a new architectural design do you?

But I do think Jed's point remains true and that some of the issue could be avoided by understanding the architecture of ID's in TW before starting. BUT which you could NOT do because you didn't yet know enough. It is a sort of puzzle. But I think it comes out okay in the end.

Josiah

[Brady77]

Hi Mark,

If you're using the uni-link plugin, it will automatically change how your links are rendered to match either the caption or the subtitle of the linked tiddler. You can then leave the tiddler alone, never renaming it but only changing "caption" or "subtitle" if you want to change how it looks when linked.

This is great as it partially solves the problem. I'll give the plugin a try a will let you know it works for me.

 

Basically, it allows you to use the title as a true immutable ID, and the caption or subtitle as the title.

How is this ID generated by the uni-link plugin? Or should I provide one by hand (from https://www.uuidgenerator.net/ for example?) Or use a system that you suggested above (<date> <topic> [<user>])?

 

It's a partial solution because it doesn't fix existing broken links. You will have to find and fix them.

No big deal with my notes so far cause I just started to use TiddlyWiki.

 

There's also nothing to prevent you from forgetting and changing a tiddler title. The title of the tiddler that appears will be different than the title someone clicked on. Perhaps the ViewTemplate could be modified to also use the caption or subtitle, reducing confusion.

I hope for some guide to help me with this. I wish to share the Wiki with other users and cannot imagine to explain everyone that this first editable field is NO-NO editable field that breaks all.

Everyone so far admitted that the tiddler should be identified by an immutable ID (call it how you want) to keep Wiki relationships operational. Why not to change the system so it is the default when starting a new Tiddlywiki? We should seriously discuss all the PROS and CONS.

Thank you, too.

[Jed Carty]

I don't really see the need for it to be immutable, so that point isn't universally agreed upon. There are a number of things in tiddlywiki that are done by overwriting a tiddler based on the name. Almost any time you change a setting that has a default value in the core you create a new tiddler that has the same name as the core tiddler. While tiddlywiki can be used as a database it isn't a database. For everything I do relationships between tiddlers are handled using tags and other fields to generate the needed links or relationships, the names almost never come into it.

[Brady77]

Josiah wrote:

I mean, you don't want to backtrack now to a new architectural design do you?

...whatever that sorts this problem I take it

 

But I do think Jed's point remains true and that some of the issue could be avoided by understanding the architecture of ID's in TW before starting. BUT which you could NOT do because you didn't yet know enough. It is a sort of puzzle. But I think it comes out okay in the end.

This is what I wanted to express at the beginning with the analogy to the dam on the river. I started to build the Wiki as my note-taking system and it broke in a way that I wasn't able to fix it. If you change the title once how can you recall it's title a few days later? And I changed many titles many times. What I ended with was a mess. Since this is the core functionality (linking tiddlers together) I'm still convinced that this is a major problem of the system core (or design if you want). 

[Mark S.]

On Tuesday, April 17, 2018 at 9:37:01 AM UTC-7, Brady77 wrote:

How is this ID generated by the uni-link plugin? Or should I provide one by hand (from https://www.uuidgenerator.net/ for example?) Or use a system that you suggested above (<date> <topic> [<user>])?

 

I would use the human-readable version I suggested. Using a UUID generator would be overkill at this point. Currently there's a functional upper limit to the number of tiddlers, so you're not going to use it as a 100000 tiddler database
 
 

I hope for some guide to help me with this. I wish to share the Wiki with other users and cannot imagine to explain everyone that this first editable field is NO-NO editable field that breaks all.

It's only a NO-NO if you plan to link to it. If you're just going to reference it by tags or fields like Jed suggests, then there's no problem. So it depends a lot on your use-case.
 

-- Mark

[Mark S.]

We're kind of going back and forth on what's easiest for the beginner. I think you may be over-qualified as a beginner.

Most beginner's instinct will be to connect notes by linking. That's what Wikis are all about, isn't it? In which case they need to understand quickly the consequences of their name choices. Other Wikis they have encountered may offer to change links when a title changes, so this may come as a surprise.

Once you're using the title for linking, the title either needs to be immutable, or you have to be willing to accept that you will have broken links.

-- Mark

[Jed Carty]

That is a good point. As someone who is no longer qualified to be a beginner, what is the alternative being presented?

If it is just "Display something other than the title in the title field" we can do that by a plugin easily enough, or add an option to toggle the template between the current version and using the caption or something.

If it is to reengineer how linking works than we need an alternative that doesn't break tiddlywiki.

[@TiddlyTweeter]

Josiah wrote:

... some of the issue could be avoided by understanding the architecture of ID's in TW before starting. BUT which you could NOT do because you didn't yet know enough. It is a sort of puzzle ...

Brady77 wrote:

This is what I wanted to express at the beginning with the analogy to the dam on the river.

 
I hear you.

..I started to build the Wiki as my note-taking system and it broke in a way that I wasn't able to fix it... I changed many titles many times. What I ended with was a mess.

Right. You can end up with a mid-town mess. That is neither fish nor fowl.

... Since this is the core functionality (linking tiddlers together) I'm still convinced that this is a major problem of the system core ... 

I agree it is very confusing.

Part of the issue is the idea of creating a Tiddler gets easily conceptually confused with creating a data record. This is something I have written at length about--that TiddlyWiki is NOT a "card-index"--though you can make it look like one. Usually when you create a record in software it creates a unique protected ID for a new record separate from whatever its user fillable fields add. Not so with Tiddlers. The "title" IS the ID. On the one hand its flexibly lightweight. On the other hand it adds complications. Especially if you need extensive inter-linking and need to change titling as you go along.

As far as I understand it, within the current basic architecture, fundamentally changing that behaviour is not possible. So its more about accepting it or finding ways round it.

Best wishes
Josiah

[Mark S.]

How about ...

When a tiddler is brand new, the user can edit both the title (which will be called title/id) and the sub-title (which will be above the title field). The title will have a suggested, date-and-userstamped title (why stamped? more below) After a tiddler is saved once and then subsequently edited, the editor will only present the subtitle field for editing, though it will present the title for copying. A user can turn off this behavior in the configuration, will have verbiage about the consequences of changing titles.

All of this will just impact the UI and possibly the documentation. Internally, everything can work as before. The date-stamped title will help prevent conflict when dragging tiddlers between TW instances (because otherwise there are going to be lots of 'New Tiddler 1' conflicts).

Ideally the core would also offer something like uni-link, but even if it doesn't the user can make their own pretty link with whatever title they want.

----

Another solution would be a plugin that detects when a tiddler is being saved with a new title. Then, just like with tag tiddlers now, it will offer to find and change all matching tiddler links. Of course, this wouldn't help anyone who has a link from another TW instance.

-- Mark

[Brady77]

Jed Carty wrote:

I don't really see the need for it to be immutable, so that point isn't universally agreed upon. There are a number of things in tiddlywiki that are done by overwriting a tiddler based on the name. Almost any time you change a setting that has a default value in the core you create a new tiddler that has the same name as the core tiddler.

You are right Jed. It was premature to state that. 

 

While tiddlywiki can be used as a database it isn't a database. For everything I do relationships between tiddlers are handled using tags and other fields to generate the needed links or relationships, the names almost never come into it.

According to the official documentation (Philosophy of Tiddlers and Structuring TiddlyWiki) there are five basic building blocks to structure the Wiki:

1. Tiddlers - only field that is required is the title field
2. TiddlerLinks - link to a tiddler by title [[Tiddler Title]]
3. Tagging - "A tag is in fact just a tiddler (or a potential tiddler), and it can have tags of its own. You can add any number of tags to the same tiddler." - If tag is internally a tiddler then 1. applies
4. Title Lists - "A title list is a line of text that presents one or more tiddler titles" - is based on tiddler titles
5. DataTiddlers - named properties are accessed by referencing the data tiddler title again

I didn't examine any important functions (like searching etc) but so far it is obvious that the tiddler title should not be modified not just because of the links, but because of other building blocks as well. It is true at the same time that there are special cases when it is desirable to change or set the tiddler title (as Josiah stated above).

[TonyM]

Brady et al..

I find this discussion quite interesting because this issue is never one I am concerned about. Using the uni-link plugin also seems to solve all other cases I can imagine. Is it because I am really good at selecting Titles or the fact I usually establish relationships through other mechanisms such as tagging? I can personally see applications where I would establish fields and or tagging to handle tiddlers with a large number of related tiddlers such as adding paragraph and chapter values so including tiddlers or relationships uses a programmatic method which does not care about the tiddlers title to work and thus can be renamed without damage.

Can you describe what kind of use or method you have that is making your solution title sensitive and I may be able to suggest an alternative?

I typically only transclude in a tiddler {{tiddlername}} if it is code or systems design where I do not care what the name is, only that I have the correct name. If I Found my self with [[no longer appropriate title to appear in text]] I would use  [[newtitle|no longer appropriate title to appear in text]] as Mario suggested, or I would rename the tiddler and its reference(s). This is not a problem if it is occasional and if it was a problem because the item was referred to in many places I would find a programmatic way to implement it.

Lets also consider, what If I am using a large set of titles I expect may need lots of renaming, I can use the pretty link, caption or uni-links plugin to help (I find this hard to believe this is not enough), but if I had this problem, then I would find a programmatic solution to this. You could use an intermediate Glossary as an index to the original tiddler using a unique value in a field, then use macros to insert the tiddler what ever its name.

What I say is if and when you are inserting into a tiddler a Link or Transclusion to another tiddler ask your self could I possibly need to change the name, not only here but in many places then just do not do it, find another solution.

Please define the occasions where this is occurring and let me suggest a solution. I love these kinds of challenges, and I seem not to have the problem you are voicing.

Regards

Tony

[Brady77]

@TiddlyTweeter wrote:

Part of the issue is the idea of creating a Tiddler gets easily conceptually confused with creating a data record. This is something I have written at length about--that TiddlyWiki is NOT a "card-index"--though you can make it look like one. 

Well, Josiah, I wasn't the one who came with the idea of creating a TiddlyWiki. Probably the best here would be asking Jeremy Ruston what was his initial vision and the intended usage of tiddlers and other basic building blocks. From your responses I feel I'm crossing some borders of fair-play when questioning basic functionality of the system. I really don't want to point at some dysfunction of the system that arises completely from my own misuse of TiddlyWiki. I'm well aware how much effort and time you spend to have a perfect system.  

Usually when you create a record in software it creates a unique protected ID for a new record separate from whatever its user fillable fields add.

This is exactly the behavior that I expected from TiddlyWiki. Let's have a look at the Airtable app for instance that I use a lot for tabular data: Whenever you create a new record (a row in a table) it gets an internal ID that you don't see and cannot access for editing. You can even create an empty row in a table (that is perfectly correct)  and then create relationships from other tables just by pointing to the row. At the same time each table has a "key" column that is used to simplify the linking of records, searching or filtering. It is a fully functional structure to be modified to my needs. If you overwrite the value in the "key" cell than all the linked records in other tables are automatically updated as well. 

 

Not so with Tiddlers. The "title" IS the ID. On the one hand its flexibly lightweight. On the other hand it adds complications. Especially if you need extensive inter-linking and need to change titling as you go along. As far as I understand it, within the current basic architecture, fundamentally changing that behaviour is not possible. So its more about accepting it or finding ways round it.

I see. Maybe some quick analysis by the system architect will help to express 

• the amount of work to bring this flexibility
• the consequences on your plugins etc.

Thanks again for spending your time and the patience you have with me, Josiah (and others as well).

Petr

[Jeremy Ruston]

Hi Brady

To clarify my earlier postings, my own view is that TiddlyWiki’s design in the area of titles, IDs etc. is correct but incomplete.

Since the main thread we’ve added automated relinking of tags and lists, but the big component that is still missing is a decent search and replace operation that is syntactically aware; it can reliably find and replace all the references to a tiddler (without being confused by plain text references to the same text). Almost everything else that one might to change is within the parts of TiddlyWiki’s UI that are expressed in wikitext.

In my own usage of TiddlyWiki I use a variety of techniques depending on the situation. One technique that is useful when working with links embedded in narrative text (as opposed to auto-generated links), is to indirect through a field: put the target of a link in a field (eg, “link-0”, “link-1”, “link-2" etc,) and then refer to them via a macro (eg, “<<link 43 ‘The original document’>>”).

Best wishes

Jeremy.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.

Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/69853bd3-6ad8-4e5b-9340-41b3bc0d5c5a%40googlegroups.com.

[Miroslav Kalous]

Jeremy, would you mind elaborating a bit further on the indirecting workaround? From your short description I don't really understand how this should work and be used (I am sorry my knowledge of TW is still limited). Do you mean creating an arbitrary new field, i.e. named "link", and filling in some number as its value? By "refer to them via a macro" you mean using the macro in a place where a normal link with square brackets would normally be? What if I change later the title ("The original document").

Moreover, 

since the issue of Link Breakage is a perennial one, what about describing existing workarounds and plugins on one page at tiddlywiki.com? It is certainly an issue that deters some people from using TW (e.g. in note-taking/Zettelkasten community). I am willing to put this page together - but I don't get a lot of these workarounds yet. I can still prepare a draft if somebody's gonna revise and finish and publish it.

[Brady77]

@PMario: 

I spent some time with the uni-link plugin to see how it works for me. First I have to say that it is very close to be a good workaround for "broken links" problem. I have a couple of questions. 

1. In the advanced search
• Can I use caption / subtitle values in the standard search tab?
• Is it possible to display the results from the filter as a list of captions / subtitles?
2. I tried your "stant-01" theme as well. 
• Is possible in the edit mode to show the tiddler title as a field at the bottom and hide it at the top?

@ Mark.S

Point 2 is probably close to what you have mentioned earlier as well.

@ TonyM

Thanks for offering your help as well. I'm building my personal knowledge base to so I can be more effective at my job. I work as an network engineer and I'm dealing with quite complex information. Partly I have to deeply understand some networking topics, partly to remember some workflows (tutorials, how-tos, guides etc.). This knowledge changes quite often as the technology evolves and so I need my tiddlers to reflect those changes as well. This is especially true while studying something new: at the beginning I decide for a name of tiddler and later I realize that this name is completely wrong (just becase I knew almost nothing about the topic at the beginning). To put it simple: I need some flexibility to only at modifying the text field, but also by naming the tiddlers. I can certainly live with the uni-link plugin regarding the "broken-links" problem. But there are some important functions that lack the support for captions / subtitles (see my questions at the beginning). So we can discuss it further.

@Jeremy Ruston

Hi Jeremy! 

1. Sorry I didn't get what you proposed (as well as @Miroslav Kalous). What problem does it solve? Maybe some example will help. Thanks.
   
2. Can you compare the difficulty of
• preparing a new release of TiddlyWiki that deals with tiddlers (and other building blocks) as objects that can be referenced independently on the user text-fields? Same functionality as I mentioned above while talking about Airtable interface.
• fixing broken links and functions (filters, lists, macros etc) on the fly after the tiddler ID changed
3. Could you explain in more detail what is the difference between changing tiddler title and tag name? What if I use a tiddler as a tag?

Thank you.

Petr

[Mark S.]

On Wednesday, April 18, 2018 at 6:07:56 AM UTC-7, Brady77 wrote:

Could you explain in more detail what is the difference between changing tiddler title and tag name? What if I use a tiddler as a tag?

This part has been automated. If  a tiddler title is the same as a tag name, and you change the title, a small dialogue will appear below the title field offering to change all the tags to reflect this change.

" Update <MyOldTitle> to <MyNewTitle> in the tags and list fields of other tiddlers"

Of course, it won't be able to change the tag name in any macros you previously invoked or defined with "MyOldTitle".

-- Mark

[Jeremy Ruston]

Hi Miroslav

Jeremy, would you mind elaborating a bit further on the indirecting workaround? From your short description I don't really understand how this should work and be used (I am sorry my knowledge of TW is still limited). Do you mean creating an arbitrary new field, i.e. named "link", and filling in some number as its value? By "refer to them via a macro" you mean using the macro in a place where a normal link with square brackets would normally be? What if I change later the title ("The original document”).

Sorry for being cryptic. The idea is that:

* Links from one tiddler to another are represented as fields on the “from” tiddler whose name starts with “link-“ followed by a unique index, with the value of the field being the title of the target tiddler

* Links within the narrative text of the “from” tiddler are written via a macro that extracts the link target given the link index number, something along the line of:

\define link(number,text)

<$link to={{!!link-$number$}}>$text$</$link>

\end

With this arrangement, one avoids having literal tiddler links within the text, and can instead manipulate the link fields very easily.

since the issue of Link Breakage is a perennial one, what about describing existing workarounds and plugins on one page at tiddlywiki.com? It is certainly an issue that deters some people from using TW (e.g. in note-taking/Zettelkasten community). I am willing to put this page together - but I don't get a lot of these workarounds yet. I can still prepare a draft if somebody's gonna revise and finish and publish it.

The docs on tiddlywiki.com could certainly be improved, and we’d welcome contributions. I’m also open to improvements that make it easier to use both approaches:

* using the title field as a GUID and the caption field as the human readable title

* using search and replace to relink references to renamed titles

Best wishes

Jeremy.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/bcb6a8fe-ab29-4f73-8948-e4adbabaece2%40googlegroups.com.

[Jeremy Ruston]

Hi Brady

1. 
   Sorry I didn't get what you proposed (as well as @Miroslav Kalous). What problem does it solve? Maybe some example will help. Thanks.
   

Perhaps my earlier reply helps?

2. Can you compare the difficulty of
• preparing a new release of TiddlyWiki that deals with tiddlers (and other building blocks) as objects that can be referenced independently on the user text-fields? Same functionality as I mentioned above while talking about Airtable interface.

Are you asking about the ability to refer to a tiddler by a field other than it’s title? 

• fixing broken links and functions (filters, lists, macros etc) on the fly after the tiddler ID changed

Do you mean by using search and replace?

3. Could you explain in more detail what is the difference between changing tiddler title and tag name? What if I use a tiddler as a tag?

"Changing a tiddler title" actually means deleting it and recreating a new tiddler with the same fields but the new title. “Changing a tag name” means both:

* renaming a tiddler that is being used as a tag

* changing references to that tiddler in the “tags” field of other tiddlers

Best wishes

Jeremy

Thank you.

Petr

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/db19508e-7ae5-4275-8140-8c17c2bc4c5e%40googlegroups.com.

[Mark S.]

On Wednesday, April 18, 2018 at 7:41:47 AM UTC-7, Jeremy Ruston wrote:

With this arrangement, one avoids having literal tiddler links within the text, and can instead manipulate the link fields very easily.

But you still have to change all field references when you change a title, so it seems like the same problem exists.

IF the auto update of "list and tag fields" that happens when changing tiddler titles could be made to include other designated fields, (e.g. matching link-*) then the fields would be updated automatically whenever a corresponding title was changed. 

Thanks,
-- Mark

[Jeremy Ruston]

Hi Mark

But you still have to change all field references when you change a title, so it seems like the same problem exists.

It’s much easier to whizz through all tiddlers looking for all the field names with a given prefix, and assign a new value, than it is to do a search and replace across the text field. The particular problem with search and replace is that it is very brittle. If I have a tiddler called “tiddler”, say, and rename it, I don’t want all the “<$tiddler>” widgets to also be reassigned.

IF the auto update of "list and tag fields" that happens when changing tiddler titles could be made to include other designated fields, (e.g. matching link-*) then the fields would be updated automatically whenever a corresponding title was changed. 

Exactly that, it would be a very modest extension of the existing relinking code.

https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/wiki-bulkops.js

Best wishes

Jeremy.

Thanks,
-- Mark

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/9f7fd0e9-9ce9-408a-a8fc-cf19b2a6b714%40googlegroups.com.

[Mark S.]

If you're going to fix the problem with macros, then you could just create your own ID field with a regular distinct pattern ("A0001","A0002",ktc)

Then use a macro like (though more sophisticated than):

\define link(id desc) <$list filter="[search:id[$id$]limit[1]]"><$link>$desc$</$link></$list>

And make your references like <<link "A0001" "Notes re comparison Disc World and Moby Dick">>

Of course, then you have to remember to assign a unique id to anything that you plan to link to.

-- Mark

[Brady77]

Jeremy Ruston wrote:

2. Can you compare the difficulty of
• preparing a new release of TiddlyWiki that deals with tiddlers (and other building blocks) as objects that can be referenced independently on the user text-fields? Same functionality as I mentioned above while talking about Airtable interface.

Are you asking about the ability to refer to a tiddler by a field other than it’s title? 

Yes. Let me explain it by workflow. Say I start with a new TiddlyWiki:

1. Create my first tiddler with no title

1a. Hit the plus button

1b. Leave the title field empty

- by empty I mean nothing there - no prefilled title

1c. Type "My first lovely tiddler" into the textarea

1d. Save and close the tiddler

Notes:

- behind the scenes the tiddler gets some system values like an internal unique ID, created time-stamp, modified time-stamp, owner ID, last editor ID (you name it)

 

2. Want to see what I have now in my Wiki

2a. Go to right-side panel

2b. Visit the list of recent tiddlers

- there is one row on the list with title "(empty)" 

Notes: 

- the word "empty" in parentheses and italic indicates that there is no tiddler title filled in

 

3. Create another tiddler with a link to the first

3a. Leave the title field empty

3b. Go to the textarea and click the link button (or Ctrl-l)

- the modal shows me input field for searching

- below the input field there is a section called "5 recent tiddlers" with one row listed as (empty)

3d. Choose the row with title (empty)

- the textarea has now a clickable link shown as (empty)

3e. Type "My second lovely tiddler" on a row below the link 

3f. Save and close the tiddler

 

4. Revisit the list of recent tiddlers

- there are two rows now

- each row has the same title (empty)

 

5. Now I want to find my first tiddler via advanced search

5a. Click the magnifier icon from the right-side panel

5b. Go to the Standard search tab and type "lovely" there

- I get two rows with title (empty)

- oops: what to choose? no way to distinguish between those two tiddlers just by title (empty)

- have to make some corrections...

 

 6. Want to change the title of the first tiddler

6a. Select the tiddler at the bottom of the recent tiddlers list

- should be the first one that I added to my Wiki

6b. Open the tiddler for editing and enter "First one" into the title

6e. Save and close the tiddler

 

 7. Review the link in my second tiddler and change the title as well

7a. Select the only (empty) title from the recent tiddlers list

- the link title in the text area has changed already to "First one"

- clicking the link bring me to the tiddler First one - nothing is broken 

7b. Open second tiddler for editing and change the title from nothing to "Second"

7c. Save and close the second tiddler

  

From the user perspective the "key" field remains the tiddler title. Output from important functions like searching are filtering remains the same: the tiddler title. But internally (for instance links between tiddlers) the system uses the tiddler ID for the URI. Should the interface be more geeky while creating links to avoid the link button, there could be an autofill function as you start typing [[. 

• fixing broken links and functions (filters, lists, macros etc) on the fly after the tiddler ID changed

Do you mean by using search and replace?

No, Jeremy, I'm referring to the auto-correction processes that must run behind the scenes each time I decide to change the tag or tiddler title. You said that it is very difficult to parse all the wiki tiddlers correctly so that only relevant parts are auto-magically changed to reflect the new title. Tags are probably much easier to change than the titles. 

So I wanted to know your expert opinion: What is more difficult? 1) Change the system so it works as described by the workflow above or 2) Try to find the correct algorithm to auto-magically correct what is broken.

Thanks for your time, Jeremy.

Petr

PS: I'm well aware of all the workarounds that already exists (including the uni-link plugin, special themes etc). I just want to know whether a system change isn't more robust, user-friendly (avoiding errors and confusions, installing special plugins), simpler, consistent and straightforward and long-lasting than workarounds.

[Jeremy Ruston]

Hi Brady

Yes. Let me explain it by workflow. Say I start with a new TiddlyWiki:

OK, you’re describing what I think of as the “GUID approach”. It’s a nice pattern, and definitely resonates with a lot of users. I don’t see it as requiring a major change to the TW core design, though: it’s predominantly high level UI entities that would need to change (eg the edit template). Personally, I’m not a huge fan because of the unreadability of link targets, but I’d like TW5 to support it for those that want it.

• fixing broken links and functions (filters, lists, macros etc) on the fly after the tiddler ID changed

Do you mean by using search and replace?

No, Jeremy, I'm referring to the auto-correction processes that must run behind the scenes each time I decide to change the tag or tiddler title. You said that it is very difficult to parse all the wiki tiddlers correctly so that only relevant parts are auto-magically changed to reflect the new title.

What I was driving at was that a naive search-and-replace algorithm would be insufficient in some situations. A syntax-aware search-and-replace mechanism isn’t too tricky: there’s already syntax-aware search in the form of the feature that extracts outgoing links from a tiddler. It does so by searching the tree resulting from parsing the text, rather than searching the text directly. Adding the replace part isn’t too tricky; in fact, it would probably be one of those things where the complexity isn’t in the mechanism but rather the user interface needed to drive it.

Tags are probably much easier to change than the titles. 

Yes indeed, and TW already offers the ability to relink tags when renaming a tiddler.

So I wanted to know your expert opinion: What is more difficult? 1) Change the system so it works as described by the workflow above or 2) Try to find the correct algorithm to auto-magically correct what is broken.

This feels like a false dichotomy. “Changing the system” implies that it wouldn’t work in the way that it does currently, which would be a problem from a backwards compatibility perspective. Perhaps the option is better expressed as “augment the system so it can work as described above”.

Anyhow, these aren’t mutually exclusive options. And of course there are also other important attributes beyond difficulty of implementation: simplicity, universality, risk, robustness, security.

But if you want to focus on implementation difficulty, option (a) touches many components of the system while (b) is a self-contained subsystem with well defined inputs and outputs. My experience suggests that the complexity of a software task depends primarily on the number of entities involved, and so I would be inclined to think of option (b) as being less difficult.

Thanks for your time, Jeremy.

No problem, thank you for the thoughtful and interesting questions. These discussions are often illuminating.

Best wishes

Jeremy.

PS: I'm well aware of all the workarounds that already exists (including the uni-link plugin, special themes etc). I just want to know whether a system change isn't more robust, user-friendly (avoiding errors and confusions, installing special plugins), simpler, consistent and straightforward and long-lasting than workarounds.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/6a92dfa7-61a7-47ae-9ae0-0a64c7dc57ab%40googlegroups.com.

[TonyM]

Mark,

I was thinking along those lines as well, I love an algorithmic challenge.

Some thoughts

In addition to your suggestion a "New Tiddler macro" or current tiddler "set ID" that assigns an ID in an additional field at creation time (see alternate below) could be used when and only when a tiddler needs to be referenced. 

An Edit toolbar helper like the current insert {{-}} or [[-]] or excise tool that inserts the <<link ID#>> from the selected  tiddler name would also make this almost transparent.

I just realised we already have and almost certainly unique identifier - creation date. On Creation, or before using as a link Extract that to the millisecond check no other tiddler exists with the same creation date (very unlikely with milliseconds) but if something else does just add 1 millisecond until you find a unique creation date. Creation dates as a rule stay the same from that point forward, even when dragged to another Wiki. We can use this as the ID for references. Simply add a field to indicate a database name if the plan is to copy move to other wikis, and add this to the ID

Regards

Tony

[Mark S.]

On Wednesday, April 18, 2018 at 8:10:01 AM UTC-7, Jeremy Ruston wrote:

IF the auto update of "list and tag fields" that happens when changing tiddler titles could be made to include other designated fields, (e.g. matching link-*) then the fields would be updated automatically whenever a corresponding title was changed. 

Exactly that, it would be a very modest extension of the existing relinking code.

https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/wiki-bulkops.js

Here's my version of bulkops. It borrows the option settings from "tags" for now.

-- Mark

/*\
title: $:/core/modules/wiki-bulkops.js
type: application/javascript
module-type: wikimethod

MAS notes: Attempt to implement auto-rename of link fields (e.g. link1-#).
Changes marked as MAS


Bulk tiddler operations such as rename.

\*/
(function(){

/*jslint node: true, browser: true */
/*global $tw: false */
"use strict";

/*
Rename a tiddler, and relink any tags or lists that reference it.
*/
function renameTiddler(fromTitle,toTitle,options) {
    fromTitle = (fromTitle || "").trim();
    toTitle = (toTitle || "").trim();
    options = options || {};
    if(fromTitle && toTitle && fromTitle !== toTitle) {
        // Rename the tiddler itself
        var oldTiddler = this.getTiddler(fromTitle),
            newTiddler = new $tw.Tiddler(oldTiddler,{title: toTitle},this.getModificationFields());
        newTiddler = $tw.hooks.invokeHook("th-renaming-tiddler",newTiddler,oldTiddler);
        this.addTiddler(newTiddler);
        this.deleteTiddler(fromTitle);
        // Rename any tags or lists that reference it
        this.relinkTiddler(fromTitle,toTitle,options)
    }
}

/*
Relink any tags or lists that reference a given tiddler
*/
function relinkTiddler(fromTitle,toTitle,options) {
    var self = this;
    fromTitle = (fromTitle || "").trim();
    toTitle = (toTitle || "").trim();
    options = options || {};
    options.dontRenameLinkFields = options.dontRenameInTags ; // MAS -- until actual option is set up somewhere
    if(fromTitle && toTitle && fromTitle !== toTitle) {
        this.each(function(tiddler,title) {
            var type = tiddler.fields.type || "";
            // Don't touch plugins or JavaScript modules
            // MAS adding 'fieldsWithLinks' for capturing fields that match pattern link-#
            // MAS adding 'changedFieldLinks' which will be filled new link-# contents if reference link changes
            if(!tiddler.fields["plugin-type"] && type !== "application/javascript") {
                var tags = (tiddler.fields.tags || []).slice(0),
                    list = (tiddler.fields.list || []).slice(0),
                    fieldsWithLinks = findlinks(tiddler.fields,/link-/),
                    changedFieldLinks = {} ,
                    isModified = false;
                if(!options.dontRenameInTags) {
                    // Rename tags
                    $tw.utils.each(tags,function (title,index) {
                        if(title === fromTitle) {
console.log("Renaming tag '" + tags[index] + "' to '" + toTitle + "' of tiddler '" + tiddler.fields.title + "'");
                            tags[index] = toTitle;
                            isModified = true;
                        }
                    });
                }
                 if(!options.dontRenameInLists) {
                    // Rename lists
                    $tw.utils.each(list,function (title,index) {
                        if(title === fromTitle) {
console.log("Renaming list item '" + list[index] + "' to '" + toTitle + "' of tiddler '" + tiddler.fields.title + "'");
                            list[index] = toTitle;
                            isModified = true;
                        }
                    });
                }


                if(!options.dontRenameLinkFields) { // MAS
                    // Rename link fields
                    var linkTitle ;
                    $tw.utils.each(fieldsWithLinks,function (linkset,index) {
                        linkTitle = (linkset.title || "").trim() ;
                        if(linkTitle == fromTitle) {
                            console.log("DEBUG Renaming link item of field " + linkset.field + " from '" + linkset.title +"' to '" + toTitle + "' of tiddler '" + tiddler.fields.title + "'");
                            changedFieldLinks[linkset.field] = toTitle;
                            isModified = true;
                        }
                    });
                }

                if(isModified) {
                    var newTiddler = new $tw.Tiddler(tiddler,changedFieldLinks,{tags:tags, list: list},self.getModificationFields())
                    newTiddler = $tw.hooks.invokeHook("th-relinking-tiddler",newTiddler,tiddler);
                    self.addTiddler(newTiddler);
                }
            }
        });
    }
};


var findlinks = function(obj, filter) {
  var key, keys = [];
    console.log("Object type " + typeof obj) ;
  for (key in obj) {
    if ( filter.test(key)) {
        keys.push({"field" :key, "title": obj[key]});
    }
  }
  return keys;
}

exports.renameTiddler = renameTiddler;
exports.relinkTiddler = relinkTiddler;

})();

[TonyM]

Brady77,

Forgive my delayed response, although you may see additional contributions in this thread.. Thanks for explaining what you are trying to do. I understand what you are trying to do because networking in one of my areas since I have being in IT for some time. I recently did some training on BigData which would be similar to your learning curve. 

I adopted TiddlyWiki Classic many years ago and still maintain a knowledge base in it but are gradually moving features and functionality into TW5.

I am confident it is only if you use [[embedded links]] or {{transclusions}} that you are likely to come across this problem because you can rename titles with no loss. 

A Common technique I use is the new here so lets say you have a "Security" subject, go to the Security tiddler and go new here to add security items, or tag them with Security. By always having a tag of the "parent" tiddler at a minimum you will always be able to list items so tagged. Renaming them changes nothing, except if they are listed in alphabetical order. You can also use the list field and a drag-able list such as a dragable table of Contents. Most of the time I access technical info I first search "titles" and "Text" then open even a related tiddler, then use the tags to refine the tiddlers I am looking at. Eg; I may search for Static IP Address, find a tiddler that mentions their use and is tagged security, open the Security tag/tiddler and review that list to find "Using Static Routes" (for Security).

Now if you feel a title is no longer valid copy the old title into the text so if you searched for it again you would find it, then modify the title.

Regards

Tony

[PMario]

Hi folks,
Very interesting discussion going on.

@Brady
Sorry for being silent even if directly mentioned. ... But I think some of your early questions about uni-link have been answered by others, in the same way, as I would have done it. ..

The tiddler.title discussion isn't new. If you search for UUID in this group you'll get discussions dating back to 2011, where TiddlyWiki 5 wasn't born yet :) (Click this link and scroll down)

I have been involved in most of them, so I thought, I'll shut up this time and see what's going on.

There is only one (short) thread that I want to point out: Federated wiki and tw

Especially Jeremy's last post, which I'll quote here, because I like his consistency over the years :)

On Friday, September 9, 2011 at 2:55:44 PM UTC+2, Jeremy Ruston wrote:

For what it's worth, my take on tiddler GUIDs is to acknowledge that
they are sometimes useful, but note that it is already possible to use
a GUID string as the title for tiddlers, and that GUIDed tiddlers can
co-exist with ordinary tiddlers. We can work around the lack of a
human readable title by, say, adopting the convention of a "display
title" field.

Cheers

Jeremy

more replies will follow.

-mario

[PMario]

On Wednesday, April 18, 2018 at 3:07:56 PM UTC+2, Brady77 wrote:

@PMario: 

I spent some time with the uni-link plugin to see how it works for me.

good.
 

First I have to say that it is very close to be a good workaround for "broken links" problem.

It was developed and introduced for this type of problems.
A bit of development history: Globally changing internal links to display caption text if possible? (only click it if you have time)
 

I have a couple of questions. 

1. In the advanced search
• Can I use caption / subtitle values in the standard search tab?

Not atm. .. But it should be easy to implement. ... That's 1 reason I wrote "partially" in my first reply. ...
 

• Is it possible to display the results from the filter as a list of captions / subtitles?

Yes, ... Someone would need to create it. ... 1 more reason, why I think uni-link plugin isn't ripe for the core .... yet ;)
 

1. I tried your "stant-01" theme as well. 
• Is possible in the edit mode to show the tiddler title as a field at the bottom and hide it at the top?

Sure. It's an opinionated theme already. .... You would just need to open: the tags/EditTemplate tiddler and modify the list field. Move the second element to the end of the list. .... BUT ... It looks strange. IMO some more UI tweaking would be needed.

have fun!
mario

[PMario]

On Friday, April 20, 2018 at 3:51:55 PM UTC+2, PMario wrote:

...

Especially Jeremy's last post, which I'll quote here, because I like his consistency over the years :)

On Friday, September 9, 2011 at 2:55:44 PM UTC+2, Jeremy Ruston wrote:

... We can work around the lack of a

human readable title by, say, adopting the convention of a "display
title" field.

I used "subtitle" as a name, because I think it "naturally" fits, for this usecase. I thought if a Wiki can have a Subtitle. A tiddler can have one too ;)

-m

[PMario]

On Tuesday, April 17, 2018 at 4:28:23 PM UTC+2, Brady77 wrote:

......

I use "real headings" at the tiddler body, which allows me to use the tiddler title as an "index" and I can change the heading as often as I want. "caption" and "subtitle" are very handy here.

This works well with the above mentioned plugins, which don't break TWs, that don't use the plugins, if you copy your texts. (but the functionality will be different!)

 

So you implemented something what Jeremy suggested in this thread above: "...users should be able to use GUIDs for tiddler titles if it suits their use case. The missing piece is a way of linking to a tiddler by it's GUID/title, but having a specified field displayed as the text of the link.".

I did implement it, because I thought in "Globally changing internal links to display caption text if possible?" Mark S. came up with a brilliant Idea, that used the wrong field. ...
and some other threads, pushed me to add the alias-functions to uni-link, to cover it in one plugin. ..
 

This is exact opposite to what Felix'es suggests by using "IDs" for GUIDs. 

May be.

-m

[Miroslav Kalous]

A little detour from the title/GUID debate:

I was wondering, and perhaps I'm not the only one, if someone has already tried to use uni-link together with modification that displays caption of a tiddler as its name (effectively using caption as title-shown but not changing title-proper)? I mean what Mark S. hinted upon: "Perhaps the ViewTemplate could be modified to also use the caption or subtitle, reducing confusion."

I think uni-link is a big help with link breakage issue. But I'd also like to view or edit a tiddler while seeing its new title, meaning caption. Otherwise I am not sure uni-link would trump the create-newly-titled-tiddler-and-translude-its-previous-version-into-it or the clone-existing-tiddler-change-its-name-and-link-its-older-version-to-it workarounds for me.

Though I don't have the least idea if such a modification of the tiddler's name behaviour is possible or how difficult it would be to make it. Thanks for any suggestions.

On Tuesday, April 17, 2018 at 6:07:34 PM UTC+2, Mark S. wrote:

If you're using the uni-link plugin, it will automatically change how your links are rendered to match either the caption or the subtitle of the linked tiddler. You can then leave the tiddler alone, never renaming it but only changing "caption" or "subtitle" if you want to change how it looks when linked.

Basically, it allows you to use the title as a true immutable ID, and the caption or subtitle as the title. But it enables better performance -- it doesn't guarantee it. It's a partial solution because it doesn't fix existing broken links. You will have to find and fix them. There's also nothing to prevent you from forgetting and changing a tiddler title. The title of the tiddler that appears will be different than the title someone clicked on. Perhaps the ViewTemplate could be modified to also use the caption or subtitle, reducing confusion.

-- Mark

On Tuesday, April 17, 2018 at 8:28:44 AM UTC-7, Brady77 wrote:

Hi Josiah,

I appreciate your willingness to help. Let's say I will generate some unique ID for tiddler title. Next I use the "caption" field to as a real tiddler title. Could you tell me what files to change so I can use it as you suggest? I'm afraid that current tiddler title is hardcoded in many places. I'm also awaiting Mario's reply regarding the "partial" solution by using the "caption" field.

Petr

[Mark S.]

The first half of that task would be to change the view templates. The view templates themselves are made up of tiddlers. If you type $:/tags/ViewTemplate under the shadow tab of the advanced search you will see the various component tiddlers listed.

There are various approaches, but this is a quick-and-dirty approach that may be good enough for most uses.

Click on and then edit $:/core/ui/ViewTemplate/subtitle .

Although this tiddler is called 'subtitle', it doesn't display a subtitle, or any title.  We will make the "subtitle" tiddler display the title field. Just put

| <$view field="title"/>

to the left of the the date view field. This will add the title to the tiddler subtitle line, but in subdued gray text.

Now click on (from the advanced search again) $:/core/ui/ViewTemplate/title and open it for editing.

Change down below where it says:

<$view field="title"/>

to

<$view field="subtitle"><$view field="title"/></$view

 What this does is create a cascade. If "subtitle" is available, it will display subtitle. Otherwise it will display the title field as a fall back.

Notice that I'm using "subtitle" and not "caption". The thing is, the caption field should always be kept short so that it can be used on menus. The subtitle can be much longer if you want.

Save and close the tiddlers. Now whenever you add a "subtitle" field to a tiddler and populate it, the contents of that field should appear as the main tiddler title.

Oh, and as always, be sure to make a backup of your TW file before trying any of this.

Maybe by tomorrow someone else will have beat me to the next task -- changing the edit templates ;-)

-- Mark

[Brady77]

Hi Jeremy again,

Jeremy Ruston wrote:

OK, you’re describing what I think of as the “GUID approach”. It’s a nice pattern, and definitely resonates with a lot of users. I don’t see it as requiring a major change to the TW core design, though: it’s predominantly high level UI entities that would need to change (eg the edit template). Personally, I’m not a huge fan because of the unreadability of link targets, but I’d like TW5 to support it for those that want it.

I really appreciate how you approached this issue. Part of user-base has found ways around this and don't consider it painful at all. Nevertheless you are still listening (to novice voices) and are open to find some solution. I would like to kindly ask you for driving (managing) the changes. There are many good reasons: you are the father of TiddlyWiki, the architect, you can balance between the pros/cons and see the consequences.

This feels like a false dichotomy. “Changing the system” implies that it wouldn’t work in the way that it does currently, which would be a problem from a backwards compatibility perspective. Perhaps the option is better expressed as “augment the system so it can work as described above”.

Yes, I know. I intentionally created this high level of contrast to push this further. Honestly, I went trough many similar discussions (as @PMario points here as well) and get completely lost - there was no real solution, ever. Even if many members tried their best to solve it reasonably (including you). I felt internally (this is solely my own opinion) that it is caused by missing support at the core - the basic building blocks lack some functionality. In another words: all the workarounds were trying (with some degree of success) to fix something that the core was supposed to do by design. Once again - I have no technical knowledge - this is solely based on what I read from discussions and what I had a chance to try as a solution. I'm telling you this with full respect to your excellent job and the brilliant idea that lasts for years. 

But if you want to focus on implementation difficulty, option (a) touches many components of the system while (b) is a self-contained subsystem with well defined inputs and outputs. My experience suggests that the complexity of a software task depends primarily on the number of entities involved, and so I would be inclined to think of option (b) as being less difficult.

To ease this discussion: like from a fairy-tale: "Which path you choose is solely in your hands. We are with you, captain! The community is hanging on your lips to follow you."

 

Best wishes to you, Jeremy.

Petr

[Brady77]

Hi Tony,

TonyM wrote:

I am confident it is only if you use [[embedded links]] or {{transclusions}} that you are likely to come across this problem because you can rename titles with no loss. 

Yes, you are right. Those are the critical spots.

 

A Common technique I use is the new here so lets say you have a "Security" subject, go to the Security tiddler and go new here to add security items, or tag them with Security. By always having a tag of the "parent" tiddler at a minimum you will always be able to list items so tagged. Renaming them changes nothing, except if they are listed in alphabetical order. You can also use the list field and a drag-able list such as a dragable table of Contents. Most of the time I access technical info I first search "titles" and "Text" then open even a related tiddler, then use the tags to refine the tiddlers I am looking at. Eg; I may search for Static IP Address, find a tiddler that mentions their use and is tagged security, open the Security tag/tiddler and review that list to find "Using Static Routes" (for Security).

What you proposed here is actually the main reason why I decided to open the Faceted search thread. We had a fruitful discussion with other members on this topic - which will hopefully lead to some improvements as well. I feel that both the links and tags create the best context for me. Thank you for your hints and inspiration.

Petr

[Brady77]

@PMario

Thank you Mario for all your comments and your plugin. To add a quick note: searching and filtering seem the most critical, now. There is no workaround I can imagine that can help here without touching the code. Don't know about transclusions since I don't use them yet.

Can I (as non-coder) be of any help here? I doubt, but let me know.

Petr

[Jeremy Ruston]

Hi Petr

Thanks for the comments, much appreciated. You make a strong case for these improvements, and I take your point that it may require my attention to make them happen. I can’t promise to work on it immediately, but I’ll try to give it some time.

In the meantime, the experiments by Mario and others might help us explore some of the UI issues.

For example, link handling will need rethinking. We’d probably want [[8EBDE50D-090C-40F0-B204-7907B4B1A780]] to produce the following wikitext:

<$link to="8EBDE50D-090C-40F0-B204-7907B4B1A780">

<$view tiddler="8EBDE50D-090C-40F0-B204-7907B4B1A780" field="caption"/>

</$link>

Right now, it produces this:

<$link to="8EBDE50D-090C-40F0-B204-7907B4B1A780">

<$text text="8EBDE50D-090C-40F0-B204-7907B4B1A780"/>

</$link>

As you’ve noted, losing easily typeable links could be mitigated by providing a popup search that is triggered on double square brackets.

Best wishes

Jeremy.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/3909b74f-6e51-462f-9c26-c2d3000f0416%40googlegroups.com.

[Mark S.]

Part Deux,

To make things easier, type $:/tags/EditTemplate into the "shadows" tab of the advanced search.

Click on

$:/core/ui/EditTemplate/title

and clone it. Rename the clone as

$:/core/ui/EditTemplate/subtitle

and replace it's contents with:

<$edit-text field="subtitle" class="tc-titlebar tc-edit-texteditor" focus="true" placeholder="Subtitle Editor"/>

Save the tiddler. This creates a special item for editing the subtitle and gives it a placeholder value. We want to make it prominent at the top. From the advanced search click on

$:/tags/EditTemplate

Go down to the "list" field. Copy and paste the $:/core/ui/EditTemplate/title in place. Then change the first $:/core/ui/EditTemplate/title  to $:/core/ui/EditTemplate/subtitle.

Save the tiddler.

Open the $:/core/ui/EditTemplate/title tiddler. From the first widget, inside the "class" attribute, delete the "tc-titlebar" class. This will reduce the size of the title field (which you may still need to edit) without eliminating it.

The same caveats about backing up previously mentioned still apply, of course.

One last change you might want to make. You might want to open tiddler

$:/language/DefaultNewTiddlerTitle

And change the default text to something that reflects, perhaps, your name and the contents of your tiddlywiki. Why? Because you may want to drag and drop your tiddlers into other TW's and there will be fewer clashes if your default name wasn't "New Tiddler", "New Tiddler 1", etc.

HTH

-- Mark

On Friday, April 20, 2018 at 11:49:11 AM UTC-7, Miroslav Kalous wrote:

[PMario]

On Saturday, April 21, 2018 at 6:52:08 PM UTC+2, Jeremy Ruston wrote:

For example, link handling will need rethinking. We’d probably want [[8EBDE50D-090C-40F0-B204-7907B4B1A780]] to produce the following wikitext:

Hi,

The uni-link code contains 2 macro tiddlers ... the uni-link-macro and the aka-macro

eg: aka ... Is called if you use a link like this: [[alias-text|?]] ... So you can basically change, the macro, to any elements you want to display. ... So if the 8EBDE50D-090C-40F0-B204-

7907B4B1A780 tiddler will contain an aliases field it should already work out of the box. ... including alias backlinks.

https://wikilabs.github.io/editions/uni-link/#%24%3A%2Fplugins%2Fwikilabs%2Funi-link%2Faka-macros:%24%3A%2Fplugins%2Fwikilabs%2Funi-link%2Faka-macros%20%24%3A%2Fplugins%2Fwikilabs%2Funi-link%2Funi-link-macro

There is some stuff missing. ... But the basics should be there for experimenting.

have fun!
mario

[Kalmir]

Mark S.,

thanks a lot, works like a charm!

[Vytas]

As a new TiddlyWiki user, I also find the possibility of "renaming tiddlers without breaking the links" to be significant. That's why I think this discussion is both very interesting and important! 

From the BEGINNER's perspective, with the following points, I'd argue for the SIMPLEST possible method of "renaming tiddlers without breaking the links":

a) LINKING is the FIRST thing you want to start doing once you become a user of TiddlyWiki. 

b) The SIMPLEST thing to do is to use the simplest linking syntax: [[Tiddler title]].

c) Especially in the beginning, you WILL WANT to RENAME tiddlers, since you have not developed the naming system yet.

d) You begin with simple things, that's why, in the beginning, you WILL NOT care/know much about captions, subtitles, aliases, UUIDs, linking via "link-fields" (proposal by Jeremy), problem solving macros/plugins and so on. 

e) You SEE your tiddler TITLE all the time (its text is large and comes in front) and you try to use it immediately. It is both the representative for the content of your tiddler and the identifier of your tiddler (to produce links).

In recent weeks, I have gained a little bit experience in TiddlyWiki and I've also noticed that the creation dates are almost unique. That is why, having read the posts in this thread, I'd like to say that the following views by Mark and Tony resonate with me:  

Mark S. wrote: "My general formulation for unique titles is <date> <topic> [<user>]"

TonyM wrote: "In addition to your suggestion a "New Tiddler macro" or current tiddler "set ID" that assigns an ID in an additional field at creation time (see alternate below) could be used when and only when a tiddler needs to be referenced. An Edit toolbar helper like the current insert {{-}} or [[-]] or excise tool that inserts the <<link ID#>> from the selected  tiddler name would also make this almost transparent."

If, as Jeremy points, a) enforcing of TWO uniquely-valued fields (title and id) per tiddler would be too expensive, and b) UUIDs are typically unreadable, 

one could then elaborate on Mark's and Tony's ideas and:

1. Have an ID field created automatically at the creation time of tiddler, or, to improve readability of IDs, have a button in the edit toolbar which would create an ID (for the tiddler with title "First tiddler title" and creation time "20180422140830123") of the following form: "2018-04-08-First-tiddler-title-14:08:30-123ms". If you are not satisfied with some abstract automatically generated ID, you could then press that button at the time when you are about to create your first link to the tiddler under consideration (or whenever you think the current title of the tiddler is suitable to generate the ID from). [After pressing the button, a warning could also pop up, explaining that changing the id would break the existing links.] 
2. Have a second button in the edit toolbar that would replace the selection Actual tiddler title with <$list filter=[field:id[2018-04-08-First-tiddler-title-14:08:30-123ms]!has[draft.of]] />.

Vytas

[Brady77]

@Jeremy, @PMario, @Mark S.

Thank you very much, Jeremy.

According the uni-link plugin: I was using the uni-link macro from the bundle, only. Why? Because the alias-macro "just" gives you more options for referencing given tiddler. In case you change tiddler alias (for whatever reason you may have) you end up with broken links, again. I like the idea of aliases but only if they would allow for renaming as well. Should Jeremy come with a "structural solution" for this topic, aliases may be considered, too.

We have now three components of current workarounds:

• uni-link plugin (PMario)
• slant-01 theme (PMario)
• some direct edits (Mark S.)

What I do miss a lot is a support for captions / subtitles while searching or filtering. Is there anyone to help with this, too? Thanks.

Petr

[Vytas]

I've done some work regarding linking via the id field (along the lines of I have talked about a couple of posts above). 

The essence is that, with two clicks in a ViewToolbar (you can reduce it to one click, if you don't mind skipping the confirmation step), you can generate a very readable id for any given tiddler from its creation date and title. Then you can link to this tiddler via its id. For this you need to write tiddler's title, select it and excise (one click in the EditorToolbar). Then you insert a macro (second click in the EditorToolbar). The macro produces the link and is of the following form: <<linktoid "id">>.

If you think it might be of some use, you can check the discussion thread dedicated to this tool: https://groups.google.com/forum/#!topic/tiddlywiki/DiowJLeoJbw .

[Brady77]

Hi Vytas,

I will not comment on the 'technical' side of your solution because I'm just an end-user. Nevertheless: in this particular case I would probably wait for Jeremy's decision. I'm trying to avoid any direct links between tiddlers, now. In other words I'm following Tony's recommendation to use tags, only.

Please forgive me my openness but I think that in this phase a birds-eye overview or high-level description of your approach to this issue (what, why, how, pros, cons) would be more beneficial to coding something not yet agreed upon. My reasons for posting this are as follows: not everyone in this discussion is a coder (including me) so I/we cannot comment on it even if the issue touches my workflow significantly. Another problem is that my current wiki may become corrupt soon since I'm trying any proposed solutions above (with backups, for sure) without understanding the impact on system if combined. 

Thank you for your comments and the proposal.

Petr

[Vytas]

Petr,

I am also not a coder. I just found the problem to be really important and took the opportunity to learn more about the TW mark-up language by trying to do something which seemed to be doable. With some dedicated time and patience, this "tool" resulted mostly from browsing the official TW website, searching the forum, putting other peoples' code together and from quite a lot of trial and error. If it would contribute a little bit, as Jeremy has put it, to the "experimentation" regarding this topic, I would be more than happy :)

If you are worried that your wiki could become corrupt as a result of imported solutions, I would say that the approach I proposed is quite robust, because:

The only thing I actually used was the good old ListWidget:  <$list filter=[field:id[qqu99yie1]!has[draft.of]] />   (see the first post of this thread by Felix in 2014!). So, as long as TW supports the ListWidget and the usage of fields, it will work. If you do not want to "pollute" your wiki with extraneous macros, you could replace "text=<<linktoid2 $(idvar)$>>" by "text=<<linktoid $(idvar)$>>" in the "insert-linktoid" tiddler. Then instead of <<linktoid "tiddler's_id">>  you would insert <$list filter=[field:id[tiddler's_id]!has[draft.of]] />  (I chose to use the macro just for a better readability) and you would be completely independent of any extraneous macros! That is, as soon as you do not want to use the tool anymore (for example, as soon as there is a solution in the core of TW to incorporate UUIDs or equivalent), you could delete all of the four tiddlers and your links would still work! Because the four tiddlers of the tool would ONLY assist you in generating/setting IDs and inserting links of the form <$list filter=[field:id[tiddler's_id]]/> to them, and would not play any active role afterwards. All of this you could do by hand, the buttons just save your time. 

What I personally like about this method, is that you can basically choose how the IDs will look like: for its generation you can combine the tiddler's creation date and its first title ("first title" means tiddler's title just before you are about to create the first link to it; because this is the latest time you have to choose the id) in almost any combination you can imagine. Also, you retain great readability of the wikitext!

For the future, I imagine TiddyWiki:

a) Retaining the enforced uniqueness of the title field.

b) Having for all practical purposes unique (and readable) id field.

c) Choosing a special symbol to start ids with (e.g. #) and forbidding starting titles with it. 

d) Supporting both [[title]] and [[id]] for linking, as well as the ability to refer to either title or id interchangeably (in any macro/widget, where now you have to use the title as a parameter).

[TonyM]

Vytas,

I am impressed with your solution as I understand it and your "jumping into the deep end of the pool".

I am sure your solution is effective however because I think this should be a fundimental feature of tiddlywiki I am keen to develop it further.

Personally I favor using a copy of the created date guarenteed to be unique in a field using the milliseconds to ensure this, then using the uni-link plugin to make this an alias which can always be refered to using uni-links notation. I would like to add an insert tiddler link to the editor toolbar that allows you to search tiddler titles but insert references to the unique id, that displays the current title even when it changes.

Given your expirence now what do you think?

Regards
Tony

[Vytas]

Thank you, Tony! 

Well, I don't see that the alias syntax would be already suitable to deal with ids.  [[8EBDE50D-090C-40F0-B204-7907B4B1A780|?]] would produce the correct link, but you would have to click on "8EBDE50D-090C-40F0-B204-7907B4B1A780" to get to the tiddler. So, it would not be an "ugly" link.

I would not be very happy to see only the created date in the wikitext when producing links. 20180504211727876 is almost as unreadable as "8EBDE50D-090C-40F0-B204-7907B4B1A780". Here I support Jeremy's strive for readability.

I agree, that a small search field in the EditorToolbar would be helpful. There you could enter a part of a tiddler title, get a drop-down, where you could select the tiddler you have looked for. This would insert a link via the tiddler's id and everyone would be happy. Actually, the click on the title could run a small program: if the corresponding tiddler has the id, then the program would insert the link via the id, and if the selected tiddler doesn't have the id yet, the program would generate the id (e.g., the way my tool generates IDs) and would insert the link via the id! This would be fantastic! The patience of waiting for the right time to generate the id would pay its dividends by producing a very readable ID made out of an already relatively well-chosen title! Whereas in my current tool you have to click four times to generate the id, confirm it, excise a precise title and insert a linktoid, in the method I described above, you would have to click only twice: to open a search box and to select a title. Moreover, the search function would not require that you should remember the exact title!

[TonyM]

Vytas,

May be my idea is not exactly like the alias plugin but similar. My idea is the id field need never be seen, however it could be displayed as a datetime and or database name.

The id field could be created for any new tiddler.

When you insert a link to a tiddler it uses the tiddlers current title to lookup the tiddlers unique id and inserts something like this;

[[UniqueId|?]]<!-- tiddler name at insertion or refresh-->

Which will always display as link to the tiddler

Current title of tiddler

What ever the tiddlers title at the time that will be displayed as its read.

My key use case is to introduce short titles or phrases I can use in multiple places how ever I can change them every where they are mentioned by changing the title.

I would also use a variant to transcluded the content of a tiddler whos name I can change that contains a snipit of text or even a macro.

A final varient will list both the changable title and that tiddlers content all by reference to the unchanging unique Id.

Finaly on hovering over said title or text it would be nice if a tooltip is displayed showing the content of the target tiddlers description field.

I see all this as providing a way to build content that can be developed over time.

Regards
Tony