[TW5] Improving tiddler renaming behaviour

[Jeremy Ruston]

I’ve had some time to work on TiddlyWiki in the last few days, but as sometimes happens, it was while travelling, and without access to wifi. Prompted by some recent user feedback, I decided to focus on improvements to the mechanism for renaming tiddlers: renaming an existing tiddler shows a checkbox in the edit template prompting “Update foofoo to barbar in the tags and list fields of other tiddlers”.

If the checkbox is checked when confirming the tiddler, then any references to the old tiddler title in tags or list fields of other tiddlers are relinked to point to the new title. (See screenshot below).

Note that at this point there is no attempt to perform search and replace within the “text” field, because of the potential for unintended results, but this is something that would be worth exploring for the future. Even as things stand, it makes renaming entries in a table of contents much easier.

You can try out the new feature by renaming an existing tiddler at:

http://tiddlywiki.com/prerelease

Please let me know if you run into any problems or edge cases,

Best wishes

Jeremy

[Danielo Rodríguez]

I'm curious about how the sync daemon will behave about this. Will it load all the tiddlers, change them and send them back to the sync-adaptor?

Regards

[Jeremy Ruston]

Hi Danielo

I'm curious about how the sync daemon will behave about this. Will it load all the tiddlers, change them and send them back to the sync-adaptor?

There’s no special interactions between the bulk-ops “rename” operation and the sync mechanism; the changes are just “addTiddler()” calls that the sync adaptor will eventually see via the “change” handler. The rename operation doesn’t touch the “text” field, and so does not trigger lazy loading.

Best wishes

Jeremy

Regards

--
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/f159a90f-535c-4aaf-91c8-2d128725560d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ed]

Hi, Jeremy,

Man this very practical!
I have quite some times done this by hand and somtimes refrained
from changing title because of the extra work. Thanks!
Tschüß, Edm.



Op donderdag 15 december 2016 22:36:07 UTC+1 schreef Jeremy Ruston:

[Xavier Cazin]

Hello Jeremy,

Very useful indeed!

I notice that in Node.js mode, this feature doesn't follow the "config": {
        "retain-original-tiddler-path": true
    } that I set in tiddlywiki.info to keep groups of tiddlers in various folders. Instead, changing the title also moves the tiddler in the tiddlers/ directory.

Cheers,

Xavier.

-- Xavier Cazin

--

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+unsubscribe@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/AE858BD0-5F14-4CA3-9014-4285C89A6868%40gmail.com.

[Danielo Rodríguez]

The rename operation doesn’t touch the “text” field, and so does not trigger lazy loading.

That is indeed a problem. If it does not trigger lazy loading, but it modifies the tiddler, how do you expect those changes to be persisted? They will be restricted to the lazy copy that resides on TW memory, and probably be overridden with the previous value when lazy-loading mechanism is triggered. 

Could you expand on why this is not a problem? I mean, what I'm missing that makes what I said incorrect?

[Jeremy Ruston]

Hi Xavier

I notice that in Node.js mode, this feature doesn't follow the "config": {
        "retain-original-tiddler-path": true

The function of “retain-original-tiddler-path” is that "If true, the server will generate a tiddler [[$:/config/OriginalTiddlerPaths]] containing the original file paths of each tiddler in the wiki”. It’s part of the mechanism used to implement the link from tiddlywiki.com back to github for editing tiddlers.

    } that I set in tiddlywiki.info to keep groups of tiddlers in various folders. Instead, changing the title also moves the tiddler in the tiddlers/ directory.

In TiddlyWiki, a rename operation is broken down into a deletion and a separate recreation. There’s no relationship between the two operations, nor the two tiddlers involved. In order to keep tiddlers with the same path despite being renamed we’d need to rewire things substantially to have a concept of renaming.

Best wishes

Jeremy

Cheers,

Xavier.

-- Xavier Cazin

On Thu, Dec 15, 2016 at 10:35 PM, Jeremy Ruston <jeremy...@gmail.com> wrote:

I’ve had some time to work on TiddlyWiki in the last few days, but as sometimes happens, it was while travelling, and without access to wifi. Prompted by some recent user feedback, I decided to focus on improvements to the mechanism for renaming tiddlers: renaming an existing tiddler shows a checkbox in the edit template prompting “Update foofoo to barbar in the tags and list fields of other tiddlers”.

If the checkbox is checked when confirming the tiddler, then any references to the old tiddler title in tags or list fields of other tiddlers are relinked to point to the new title. (See screenshot below).

Note that at this point there is no attempt to perform search and replace within the “text” field, because of the potential for unintended results, but this is something that would be worth exploring for the future. Even as things stand, it makes renaming entries in a table of contents much easier.

You can try out the new feature by renaming an existing tiddler at:

http://tiddlywiki.com/prerelease

Please let me know if you run into any problems or edge cases,

Best wishes

Jeremy

<PastedGraphic-1.png>

--
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+unsubscribe@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/AE858BD0-5F14-4CA3-9014-4285C89A6868%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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/CADeSwYMvsKKy3Z3tudKR2%2Bg-KDz0QR6CYkaOe1GEkw4xTFb4Lg%40mail.gmail.com.

[Jeremy Ruston]

Hi Danielo

The rename operation doesn’t touch the “text” field, and so does not trigger lazy loading.

That is indeed a problem. If it does not trigger lazy loading, but it modifies the tiddler, how do you expect those changes to be persisted? They will be restricted to the lazy copy that resides on TW memory, and probably be overridden with the previous value when lazy-loading mechanism is triggered. 

Could you expand on why this is not a problem? I mean, what I'm missing that makes what I said incorrect?

Yes, I think you’ve found one of the edge cases I was asking for!

I don’t think that there’s much we can do to fix things up in the face of lazy loading. Fundamentally, such operations need to be done on the server in such situations, and we don’t currently have the plumbing for that.

In the absence of a server side mechanism for relinking, there’s not much we can do other than think about ways to ensure that the affected tiddlers are loaded into the client before attempting a search and replace.

I guess there might be something that the syncer/sync modules could do to merge modified fields of lazily loaded tiddlers.

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/29267ba4-c5e9-46f7-b34b-3ee46b786f1d%40googlegroups.com.

[Xavier Cazin]

Jeremy,

Oh I see. Thanks for the explanation!

X.

-- Xavier Cazin

Hi Xavier

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CADeSwYMvsKKy3Z3tudKR2%2Bg-KDz0QR6CYkaOe1GEkw4xTFb4Lg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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+unsubscribe@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/809E1AC7-4965-40D7-BD9F-CD17A704149C%40gmail.com.

[Mat]

This is a very much longed for feature! Thank you Jeremy!!

Minor: The checkbox should probably reset to unchecked state after the action has been performed. 

<:-)

[Tobias Beer]

Hi Jeremy,

 

I guess there might be something that the syncer/sync modules could do to merge modified fields of lazily loaded tiddlers.

Do we have some sort of TQL (Tiddler Query Language) / process that would provide the "plumbing" to, say, run a filter against the synced-store and return a list of titles to the "frontend" which may then decide to load these tiddlers into the wiki to do the desired processing such as renaming.

Best wishes,

Tobias.

[Jeremy Ruston]

Hi Mat

This is a very much longed for feature! Thank you Jeremy!!

Minor: The checkbox should probably reset to unchecked state after the action has been performed. 

Interesting, what are the situations where one would want it switched off? I’ve found the persistence helpful, and that in practice, as long as one is aware of what’s going on, there’s no reason not to have it checked all the time. (It’s unchecked by default for backwards compatibility, but that’s arguable as well).

Best wishes

Jeremy

<:-)

On Thursday, December 15, 2016 at 10:36:07 PM UTC+1, Jeremy Ruston wrote:

I’ve had some time to work on TiddlyWiki in the last few days, but as sometimes happens, it was while travelling, and without access to wifi. Prompted by some recent user feedback, I decided to focus on improvements to the mechanism for renaming tiddlers: renaming an existing tiddler shows a checkbox in the edit template prompting “Update foofoo to barbar in the tags and list fields of other tiddlers”.

If the checkbox is checked when confirming the tiddler, then any references to the old tiddler title in tags or list fields of other tiddlers are relinked to point to the new title. (See screenshot below).

Note that at this point there is no attempt to perform search and replace within the “text” field, because of the potential for unintended results, but this is something that would be worth exploring for the future. Even as things stand, it makes renaming entries in a table of contents much easier.

You can try out the new feature by renaming an existing tiddler at:

http://tiddlywiki.com/prerelease

Please let me know if you run into any problems or edge cases,

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/35e8133c-2819-46b6-a36b-cb5e02554115%40googlegroups.com.

[Jeremy Ruston]

Hi Tobias

Do we have some sort of TQL (Tiddler Query Language) / process that would provide the "plumbing" to,

I think the existing filter language could fairly be described as a TQL

say, run a filter against the syned-store and return a list of titles to the "frontend" which may then decide to load these tiddlers into the wiki to do the desired processing such as renaming.

No, that doesn’t exist.

The difficulty is that retrieving the non-skinny versions of the tiddlers is an asynchronous operation, while the rename operation is synchronous in the UI.

But I’m not sure that shipping tiddlers to the client for operations is really the way to go (except as a temporary hack/workaround), there’s plenty of operations that we would want to perform on the server (eg batch image resizing), and we really need a robust mechanism for invoking server-based actions from the client.

Best wishes

Jeremy

Best wishes,

Tobias.

--
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/0df1b714-cad0-49be-ac1b-fcda21f4e43c%40googlegroups.com.

[Tobias Beer]

Hi Jeremy,

 

But I’m not sure that shipping tiddlers to the client for operations is really the way to go (except as a temporary hack/workaround), there’s plenty of operations that we would want to perform on the server (eg batch image resizing), and we really need a robust mechanism for invoking server-based actions from the client.

I agree, there are perhaps a few mainly server driven processes, i.e. performed against and at the server only.

In the context of renaming, I could easily imagine the renaming to very much happen in the client. The cycle would go something like this:

1. title is changed while the checkbox to update references is ticked
2. a given timout is waited
3. the synced store is queried via filters
4. affected tiddlers are listed and asyncronously loaded in full
5. while that's going on, a spinner indicates that we're still loading stuff and the save button is disabled
6. once loaded, the operation shows affected titles and the save action is activated again
7. now the full renaming operation can be peformed

Best wishes,

Tobias.

[Mat]

On Saturday, December 17, 2016 at 9:00:25 AM UTC+1, Jeremy Ruston wrote:

Minor: The checkbox should probably reset to unchecked state after the action has been performed. 

Interesting, what are the situations where one would want it switched off?

Hm, wait, I mean, it becomes default-checked for all other tiddlers too. The resulting name changes are of course tiddler specific but the checkbox state is unexpectedly global, which is why I propose that it returns to a default state. No biggie though.

<:-)

[PMario]

Hi Jeremy,

I think there are some weaknesses, that can be improved.

1) The "rename tags checkbox" is shown, even if no tiddler is tagged with the "old" name.

to reproduce:
 - create a "New Tiddler"
 - rename it

---------------------------

2) imo new feature in 5.1.14-prereleas

eg:
  - tiddler a and b exist
  - renaming tiddler a to name: b shows: "Target tiddler already exists"      <- OK
  - it also shows the rename tags checkbox.  <- see: 1)  ... imo should be changed ... but may slow down the UI

----------------------------

3) no warning, that new tiddler name is already a tag
to reproduce:

 - create tiddler a
 - create tiddler aa and tag it: a
 - create tiddler bb and tag it: b    .... make sure that tiddler b does _not_ exist!
 - no rename tiddler: a to b

IMO there should be an info, that other tiddlers use that tag already!

------ reasoning -----

IMO there should be an info, that "bb" ist tadded "b" already! ... If there is no such info, it may cause some tricky problems.

to reproduce:

 - aa is tagged a
 - bb is tagged b   ... tiddler b doesn't exist
 - rename a to b    .... now aa is also tagged b

 - ... now you find out, that "b" is the wrong name. It should be "c"

 - so you rename b to c ...-> ouch!!!   now bb is tagged c instead of b.

.. and nobody told you!!! .... that's confusing. right?

That's why I called it a tricky problem ;)

------------------------

Suggestion: After the rename mechanism did change tiddlers, there should be an info, which tiddlers have been changed! So the user knows, what was going on.


-mario

[PMario]

On Saturday, December 17, 2016 at 5:20:51 PM UTC+1, PMario wrote:

Suggestion: After the rename mechanism did change tiddlers, there should be an info, which tiddlers have been changed! So the user knows, what was going on.

Even better would be an UI, that offers a preview of the tiddlers, that will be changed, before the action happens.

May be "batch processing" should always be part of the ControlPanel and not the edit-template. Because the edit-template UI should be made simpler and not more complicated.

just some thoughts.
-m

[Danielo Rodríguez]

I totally disagree, let me expose my reasons

 

I don’t think that there’s much we can do to fix things up in the face of lazy loading. Fundamentally, such operations need to be done on the server in such situations, and we don’t currently have the plumbing for that.

....

The difficulty is that retrieving the non-skinny versions of the tiddlers is an asynchronous operation, while the rename operation is synchronous in the UI.

But I’m not sure that shipping tiddlers to the client for operations is really the way to go (except as a temporary hack/workaround), there’s plenty of operations that we would want to perform on the server (eg batch image resizing), and we really need a robust mechanism for invoking server-based actions from the client.

 

•  First, I don't see the problem on performing a batch operation like this in an asynchronous fashion. Not only when sync to server is implied, always. Because this is a batch operation that could involve a complicated logic, doing it in an asychronous fashion allows us to keep the UI responsive while doing the required changes, and of course would allow to interact with the server without any problem. For me is a win-win situation.
• Second, you are restringing the usage of remote stores to the most classic ones. Nowadays remote does not means a server that you control, it can be a database as a service, an API that allows you to retrieve and create files (dropbox, github) , and many more, server-less is becoming mainstream. Restricting an operation that can be easily performed on the client to the server architecture means restricting tiddlywiki too much, and coupling it to just a small set of compatible servers.
• Third, this can cause race conditions and weird situations. Imagine that you perform a batch operation on the client side, and asks the same operation to be performed on the server once the renaming suceeds on client. Because the operation is asynchronous, the user can try to load some of the affected tiddlers before the operation can complete on the server, then the server will deliver to you the older version, which will cause an unstable and hard to guess situation. This was a race condition and the client side won. This gets even funnier if you ask for a bunch of tiddlers and some of them are delivered BEFORE the operation completes, while others are delivered AFTER the relinking is completed, I can't imagine what kind of messy situations we can get here. Not to mention that what could happen if you perform the renaming on the client but it fails on the server? then you will be on some kind of split-brain

 

In the absence of a server side mechanism for relinking, there’s not much we can do other than think about ways to ensure that the affected tiddlers are loaded into the client before attempting a search and replace.

Where is the problem wit this approach ? For me it's perfectly valid. Tiddlywiki is a single page application, it can handle all the required logic to operate the tiddlers on the client. Why not? I can't find a valid reason to don't doing it. Let's keep tiddlwiki as functional and compatible with any server architecture as possible.  

I guess there might be something that the syncer/sync modules could do to merge modified fields of lazily loaded tiddlers.

This is, again, a complicated and unnecessary logic when you can just fetch the tiddlers and perform some POTWOs (plain old tiddlywiki operations) 

Regards.

[Jeremy Ruston]

Hi Danielo

On 18 Dec 2016, at 10:52, Danielo Rodríguez <rdan...@gmail.com> wrote:

I totally disagree, let me expose my reasons

•  First, I don't see the problem on performing a batch operation like this in an asynchronous fashion. Not only when sync to server is implied, always. Because this is a batch operation that could involve a complicated logic, doing it in an asychronous fashion allows us to keep the UI responsive while doing the required changes, and of course would allow to interact with the server without any problem. For me is a win-win situation.

Renaming is currently implemented as a synchronous operation. Yes, you could reimplement it as some kind of asynchronous operation. There’s no framework for such operations at present though. But it’s synchronous at the moment.

• Second, you are restringing the usage of remote stores to the most classic ones.

No, I am not restricting the usage of remote stores to the most classic ones. I am making an architectural point. If you want to keep the data on the server, then you need to operate on it on the server. If you move the data to the client to operate on it then you are no longer operating on it on the server. 

• Nowadays remote does not means a server that you control, it can be a database as a service, an API that allows you to retrieve and create files (dropbox, github) , and many more, server-less is becoming mainstream. Restricting an operation that can be easily performed on the client to the server architecture means restricting tiddlywiki too much, and coupling it to just a small set of compatible servers.

None of that seems relevant to my point. I’m not restricting anything; I’m making the point that we can’t within the client create a general solution to the problem of performing operations on the server.

• Third, this can cause race conditions and weird situations. Imagine that you perform a batch operation on the client side, and asks the same operation to be performed on the server once the renaming suceeds on client. Because the operation is asynchronous, the user can try to load some of the affected tiddlers before the operation can complete on the server, then the server will deliver to you the older version, which will cause an unstable and hard to guess situation. This was a race condition and the client side won. This gets even funnier if you ask for a bunch of tiddlers and some of them are delivered BEFORE the operation completes, while others are delivered AFTER the relinking is completed, I can't imagine what kind of messy situations we can get here. Not to mention that what could happen if you perform the renaming on the client but it fails on the server? then you will be on some kind of split-brain

I’m not sure what you’re saying here. What can cause race conditions? Your second sentence is making an odd assumption about performing the same operation on the client and the server; I don’t understand the relevance.

Best wishes

Jeremy.

 

In the absence of a server side mechanism for relinking, there’s not much we can do other than think about ways to ensure that the affected tiddlers are loaded into the client before attempting a search and replace.

Where is the problem wit this approach ? For me it's perfectly valid. Tiddlywiki is a single page application, it can handle all the required logic to operate the tiddlers on the client. Why not? I can't find a valid reason to don't doing it. Let's keep tiddlwiki as functional and compatible with any server architecture as possible.  

I guess there might be something that the syncer/sync modules could do to merge modified fields of lazily loaded tiddlers.

This is, again, a complicated and unnecessary logic when you can just fetch the tiddlers and perform some POTWOs (plain old tiddlywiki operations) 

Regards.

--
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/174db8d4-d254-470d-9c22-4b54a1d0dd4b%40googlegroups.com.

[Jeremy Ruston]

Hi Mario

These look like interesting proposals, I’d be happy to consider pull requests, but as you note, performance is a concern here.

1) The "rename tags checkbox" is shown, even if no tiddler is tagged with the "old" name.

I don’t understand why that matters? The text is offering to do the relinking; it’s not asserting that there are any items to be renamed.

2) imo new feature in 5.1.14-prereleas

eg:
  - tiddler a and b exist
  - renaming tiddler a to name: b shows: "Target tiddler already exists"      <- OK
  - it also shows the rename tags checkbox.  <- see: 1)  ... imo should be changed ... but may slow down the UI

Why should it not? If you want to merge two tiddlers then you’d want to relink the fields.

3) no warning, that new tiddler name is already a tag
to reproduce:

 - create tiddler a
 - create tiddler aa and tag it: a
 - create tiddler bb and tag it: b    .... make sure that tiddler b does _not_ exist!
 - no rename tiddler: a to b

IMO there should be an info, that other tiddlers use that tag already!

I don’t follow the logic. Why does the user need to know that they are renaming the tiddler to the name of an existing tag? It’s a common operation, surely?

Suggestion: After the rename mechanism did change tiddlers, there should be an info, which tiddlers have been changed! So the user knows, what was going on.

Yes, I agree. As I’ve mentioned before, the architecture of the $:/Import mechanism is designed as a general purpose “holding pen” for the review of changes before accepting them. I have recently integrated a JS diff engine too, which I’ll merge when I get a chance.

Best wishes

Jeremy

-mario

--
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/d6215b70-e79e-40d6-9c25-b95f49bcca41%40googlegroups.com.

[Mat]

I occasionally do a general google search for TW to see what shows up.

This time I stumbled over this "argumentation" which is somewhat relevant for this thread.

<:-)

[Danielo Rodríguez]

To be honest,
If we were using UUIDs instead of user's titles anything of this would matter

[Jed Carty]

While using UUIDs may simplify some things it would make others more complex. How do you overwrite a shadow tiddler if they all use UUIDs? If you are able to edit UUIDs to make a new tiddler with the same one then they aren't unique anymore, if you do something like take the tiddler with the same title and the newest modified field than you are back to having titles being the same as UUIDs. 

I think that while on the surface changing to UUIDs could take care of some things, it isn't actually solving the problems, just moving them.

[Jeremy Ruston]

I also don’t think that UUIDs are a magical solution.

For example, unless we want users to write [[my link|eaec2913b78d11a81a68775068fb3107e9029b746e7cbc6d1a1926190c9f6f05]], then we’ll want [[my link|my title]] to perform a title search to find the target tiddler.

The moment we support such a syntax then we’re back precisely where we started, where there will be a strong need for tools which relink titles.

Having said that, as I’ve noted before, there’s little preventing somebody from experimenting with a UUID-oriented variant of the default TiddlyWiki user interface. One option is to use the title field to contain a UUID but a more interesting approach is to use a separate UUID field, and take advantage of one of the properties of most UUID generation algorithms: the guarantee that each generated UUID will be unique.

Best wishes

Jeremy

On 30 Dec 2016, at 08:21, Jed Carty <inmy...@gmail.com> wrote:

While using UUIDs may simplify some things it would make others more complex. How do you overwrite a shadow tiddler if they all use UUIDs? If you are able to edit UUIDs to make a new tiddler with the same one then they aren't unique anymore, if you do something like take the tiddler with the same title and the newest modified field than you are back to having titles being the same as UUIDs. 

I think that while on the surface changing to UUIDs could take care of some things, it isn't actually solving the problems, just moving them.

--
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/fd485435-bd6c-41b2-b1b5-728b5ba882dc%40googlegroups.com.

[Tobias Beer]

Hi Jeremy,

As I did for TW2, I'm still in favor of storing old titles in a renamed list field in order to still be able to have links work, for example.

http://renametiddlers.tiddlyspace.com

Best wishes,

Tobias.

[Josiah]

UUIDs are sometimes useful. I think its depends a lot on what you are doing. Once I realised that TW doesn't serialize Tiddlers with unique UUIDs I started messing around with manipulating creation times to give surrogate UUIDs. It kinda works.

For me the lack of auto-serialisation turns up negatively the fact you can't create two tiddlers with the same title. That is irritating :-). A tiddler title, IMO, should not HAVE to be unique.

Best wishes
Josiah

[Jed Carty]

If tiddler titles needing to be unique are your complaint than we can make a plugin that displays the caption field (or whatever field is appropriate) instead of the title field on tiddlers. But linking would still require the title because a link has to be to a unique tiddler.

[Thomas Elmiger]

Hi Jeremy and Mario

Mario brought up an interesting point here:

1) The "rename tags checkbox" is shown, even if no tiddler is tagged with the "old" name.

I don’t understand why that matters? The text is offering to do the relinking; it’s not asserting that there are any items to be renamed.

Personally I would love to use this new feature anyway, because I do not rename tiddlers very often. But I have to admit that every new element in the editing interface – especially when it attracts my attention when popping up – distracts me and thus slows down the editing process. So I would like this feature even more, if it would appear only if there is something it can do for me.

All the best,
Thomas

[Dmitry Sokolov]

I would be supportive to the point of view of Tobias if I understand it right: titles of tiddlers must be unique, to be referred reliably in future.
The other reason to support is our potential transition to the IPFS protocol in near future. Human-readable links is one of the core features of P2P Web: IPFS is the Distributed Web

From my experience, #@ space (multi-user semantic space) + versioning (time) is easier to read / understand (by my customers) and works just fine (on PBWorks).

Just my 2 cents,
Dmitry

[Flibbles]

For anyone who's interested in a more comprehensive way of renaming, I've published a plugin here:

https://github.com/flibbles/tw5-relink

This allows updating of specific syntax patterns in text, filters, as well as custom fields. And whether those fields are lists, filters, or singular tiddler titles.

-Flibbles

[Mohammad]

Great addition

[TonyM]

Cobbles

I will check this out as its a critical feature for wikis.

Given the centrality of the tiddler name in tiddlywiki perhaps the ability to delete a tiddler and remove its name rather than rename would be helpful.

Perhaps you could consider a desperate delete plugin which could be based on your current plugin.

Regards
Tony

[Flibbles]

@TonyM, I'm not sure what you mean for having a plugin for deleting tiddlers.

If I have a tiddler with text:

```

Welcome to my project. Please be sure to visit the [[gift shop|Giftshop]].

```

If I remove the tiddler "Giftshop", What does this become?

[TonyM]

I was not thinking about removing tiddler names from in text, more when the list field and other fields contain tiddlername. I suppose in text we could rename it to "deleted" but I also see value leaving it in text and the tiddler can be created (recreated) with a click.

regards
Tony

[PMario]

On Tuesday, January 3, 2017 at 9:04:12 AM UTC+1, Dmitry Sokolov wrote:

I would be supportive to the point of view of Tobias if I understand it right: titles of tiddlers must be unique, to be referred reliably in future.
The other reason to support is our potential transition to the IPFS protocol in near future. Human-readable links is one of the core features of P2P Web: IPFS is the Distributed Web

Hi,

My approach is to us aliases instead of tiddler titles. Alias links don't break, if you change the tiddler title.

see: uni-link plugin

and I'm a fan of the https://dat.foundation/ and beaker-browser, which are also port of the P2P movement.

have fun!

mario

[PMario]

Sightly OT, but it talks about avoiding "broken URL links" links ...

----------------------------

On Friday, August 23, 2019 at 10:17:24 AM UTC+2, PMario wrote:

...

and I'm a fan of the https://dat.foundation/ and beaker-browser, which are also port of the P2P movement.

The cool thing with DAT and TiddlyWiki is, that they are a perfect fit. TiddlyWiki needs unique tiddler titles per wiki file. This mechanism doesn't need to change, because the "variable" part in a dat-address is the "public key", which is the first part of the address. ... So it's possible to "combine" TWs which contain tiddlers with the same name. ..

The mechanism is the same as we used in TiddlySpace: "stacked recipes". ... We can write to "spaces" where we have write access. If we don't have write access, we need to "clone" a tiddler and save it to a space, where we have write access.

Tiddlers which are overwritten, are "shadow tiddlers" ...

just some thougts.

have fun!

mario

[Jeremy Ruston]

Hi Flibbles

That’s terrific, I’m very impressed, particularly by the richness of the rules.

Best wishes

Jeremy

On Thursday, December 15, 2016 at 4:36:07 PM UTC-5, Jeremy Ruston wrote:

I’ve had some time to work on TiddlyWiki in the last few days, but as sometimes happens, it was while travelling, and without access to wifi. Prompted by some recent user feedback, I decided to focus on improvements to the mechanism for renaming tiddlers: renaming an existing tiddler shows a checkbox in the edit template prompting “Update foofoo to barbar in the tags and list fields of other tiddlers”.

If the checkbox is checked when confirming the tiddler, then any references to the old tiddler title in tags or list fields of other tiddlers are relinked to point to the new title. (See screenshot below).

Note that at this point there is no attempt to perform search and replace within the “text” field, because of the potential for unintended results, but this is something that would be worth exploring for the future. Even as things stand, it makes renaming entries in a table of contents much easier.

You can try out the new feature by renaming an existing tiddler at:

http://tiddlywiki.com/prerelease

Please let me know if you run into any problems or edge cases,

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 view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/537c9094-cc2c-4964-820a-b8e13fffacc9%40googlegroups.com.