Cloning a Cloned Tiddler without changing the auto-titles does not generate the expected Tiddler title. This traces back to generateNewTitle() in $:/core/modules/wiki.js.
Go to https://tiddlywiki.com/
Result: A new draft of "New Tiddler 1 1" is created.
Expected Result: A new draft of "New Tiddler 3" is created.
Arguments for: The user may expect the generateNewTitle() method to simply inrcement the trailing "space plus digit (non-zero-padded)" number.
[Saruman] If I clone out tiddlers "Ork 1", "Ork 2", and "Ork 3" from "Ork", then change a few thing on Ork 2, then clone _that_ _one_, shouldn't I get "Ork 4"? [/Saurman]
Arguments against: Once cloned, field values are independent of the previous "parent", treat the new title as anything else: add a trailing space plus digit (increment until unused # is found).
I think this is plugin territory.
I think this is a very special usecase. Your arguments are fine for this case, but it's not a generic behaviour.
At the moment, the rule for auto created unique titles is as follows. Cloning is a "shortcut" for "create a new tiddler and copy the whole content of tiddler x"
If you clone a name "Ork 1", it will be used as the base name. If you expect that "Ork 1" should be followed by "Ork 2", that's cool for you. .... BUT
I may expect "Ork one" should be followed by "Ork two" ... Just because my special usecase looks like this.
What if the name of the base tiddler is "Ork 1." ? .. see the dot. What if the number is "Ork 1.1"
With the existing algorithm the behaviour is 100% predictable. .. If we implement special rules for some usecases, the whole thing will get complicated. ... Both in documentation and in core code.
As I wrote. It's plugin territory. It should be possible to create a user-defined clone button, that uses your behaviour.
Thanks @joshuafontany I think you're referring to the way that wiki.generateNewTitle doesn't recognise tiddler titles that already end with a number, and instead applies a further numeric suffix. I've come across this before and agree that it is slightly unsettling. I'd be happy for it to be fixed if you'd like to have a go at it, @joshuafontany?
If it does change, IMO there has to be a configuration, which allows us to keep the old behaviour.
Eg: Using the Orks again. I do have "Ork 1", "Ork 2" and "Ork 3" where the number is meant to be connected to the level. .. So if I clone "Ork 1" to make minimal changes It shouldn't be named "Ork 4" because it means level 4, which definitely isn't the case.
It has to be "Ork 1 1" so I can see, where it belongs to.
I personally do need to see where a tiddler comes from. So "New Tiddler 1 2 1" contains the history how it was created. Even if the name is silly it contains useful information, that shouldn't be destroyed.
Thanks guys, I wasn't quite sure if this qualified as a "bug", as I can also see @pmario's argument that the chained numbers in the title do carry a type of "version" information. Thanks for talking it out with me. I also think that a toggle-able setting that defaults to the backwards compatible behavior, or something similar would be the way to go with this. I'll have to really go through the core and see where else generateNewTitle() is used.
generateNewTitle() is used at:
Most helpful comment
If it does change, IMO there has to be a configuration, which allows us to keep the old behaviour.
Eg: Using the Orks again. I do have "Ork 1", "Ork 2" and "Ork 3" where the number is meant to be connected to the level. .. So if I clone "Ork 1" to make minimal changes It shouldn't be named "Ork 4" because it means level 4, which definitely isn't the case.
It has to be "Ork 1 1" so I can see, where it belongs to.
I personally do need to see where a tiddler comes from. So "New Tiddler 1 2 1" contains the history how it was created. Even if the name is silly it contains useful information, that shouldn't be destroyed.