The behavior is exactly what I would expect. You cloned d not g. So whatever happens within d is what will be replicated on all of d's clones. If you delete g on one clone, that's what happens on the other - otherwise, they wouldn't be clones. They'd be independent copies.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@wordmuse it seems you are wrong. Please open his map. Then add any child to the upper "g". You will see that it won't be cloned to the lower "g". This is unexpected, right?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I checked, and I'm not wrong. The clone is somehow broken. I deleted one of the clones and then created my own. Now it works just fine - as expected.
I don't know why the clone in the downloaded map doesn't work, but it doesn't. I would suggest that if one comes across clones that don't behave properly, delete the branch that's not working, and create the clone anew.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, you @wordmuse are right that freeplane works correctly with a valid map. I fully agree. Nothing where I said you were wrong.
But @robertonisola uploaded a mm file that was produced/saved by/from freeplane. It turns out that the map is invalid. You seem to agree with your statement "The clone is somehow broken". I fully agree here: the problem is the line
Thank you @wordmuse for suggesting a work-around like "manually search for broken clones and manually replace them by working clones!". But I'd like to suggest trying to find and fix the root cause of this issue first.
Last edit: echo21 2019-09-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can either clone a single node without descending nodes or a subtree.
On your example it looks like you cloned a subtree, and so changes on one subtree (removing node named g) are replicated on the other.
If you delete node d, it does not change the structure of the cloned subtree. Therefore node d can be removed independently.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No matter what particular sequence @robertonisola carried out to create his map, the result seems incorrect to me: as there seems to be only 1 (twin clone) instance of "g" , it must not have a square clone symbol but a rectangular one.
I think we all agree that node "d" is a child of node "m", right? You can check this in the mm file.
Also it is obvious that a clone of node "d" is a child of node "c", or am I wrong?
As far as I understood everything that happens to node "d" or its children has to happen also to "d" node's clone.
Now simply create a new child of any of the grand-children "g" of "m" or of "c". Bang! It will not be cloned to its twin "g".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Honestly I don't remember how I created that map. The map I attached here is just a strip-down version of the full map on which I noticed this behaviour.
In order for you to fully understand my concern, I'd like to tell you my way of using clones: I often create a lot of clones when working on a project. And when this project finishes, I delete all of the clones, but I have to keep the original node.
So regarding the 'strange' behaviour I mentioned in this topic, it is dangerous to me because up until now, whenever I see a clone with a large rectangle at its left side, I assume this node can be safely deleted. And by 'safely' I mean there is still at least one node else where in the map containing the same information as the deleted node.
But in the case with node g above, I cannot safely delete g because doing so will cause all of other g(s) disappear as well.
So my ultimate question is, if I cannot rely on the large rectangle as an indicator of a cloned node, then how can I know if the node can be safely deleted? Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@robertonisola this seems to me a very complex freeplane issue. It is very helpful that you provided the map. This demonstrates the existence of invalid mm files. But I fear that this is not enough for the freeplane devs. To find and fix the issue they would IMHO need to have a method how to reproduce the creation of such an invalid mm file.
Last edit: echo21 2019-09-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The original map (which had this problem) was created and edited purely in Freeplane, using only mouse and keyboard, no script involved.
And I agree with you that it might be difficult to reproduce this problem because that map was very big with thousands of nodes, and thousands of commands (create, cut, copy, clone...) have been executed on it, and somehow a rare combination of these commands created this problem.
After all, no app is perfect so it is not uncommon for us users to encounter this kind of problems, even in Microsoft or Google products.
And, although this problem is not trivial to me, Freeplane still remains my number one mindmap app, and I will definitely continue to use it in the future. Big thanks from me to @dpolivaev and the other devs.
I just hope that one day the root cause of this problem will be found and fixed. In the mean time I will try my best to backup my maps as frequently as possible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a simple map (please see the attached picture and map).
In the map, there are 2 nodes named g, and since they both have the large rectangle at the left side, they are clone.
The strange thing is: If one of them is deleted, the other one disappears too.
This is not something I expect. What I expect is that: if a clone is deleted, then the other node should still exist.
Also in the map, there are 2 nodes named d, if I delete one of them, the other still exists. This is the correct behavior.
So could anyone please enlighten me about the situation with nodes g above? Thank you.
The behavior is exactly what I would expect. You cloned d not g. So whatever happens within d is what will be replicated on all of d's clones. If you delete g on one clone, that's what happens on the other - otherwise, they wouldn't be clones. They'd be independent copies.
If d (and all its children) was cloned, the rectangle attached to g would be small, not large.
Please take a look at the picture I attached with this reply.
@wordmuse it seems you are wrong. Please open his map. Then add any child to the upper "g". You will see that it won't be cloned to the lower "g". This is unexpected, right?
I checked, and I'm not wrong. The clone is somehow broken. I deleted one of the clones and then created my own. Now it works just fine - as expected.
I don't know why the clone in the downloaded map doesn't work, but it doesn't. I would suggest that if one comes across clones that don't behave properly, delete the branch that's not working, and create the clone anew.
Ok, you @wordmuse are right that freeplane works correctly with a valid map. I fully agree. Nothing where I said you were wrong.
But @robertonisola uploaded a mm file that was produced/saved by/from freeplane. It turns out that the map is invalid. You seem to agree with your statement "The clone is somehow broken". I fully agree here: the problem is the line
in the mm file. Instead it must be
Resume: @robertonisola , @wordmuse and me have to believe that there is a defect in freeplane. @dpolivaev , what do you think?
Thank you @wordmuse for suggesting a work-around like "manually search for broken clones and manually replace them by working clones!". But I'd like to suggest trying to find and fix the root cause of this issue first.
Last edit: echo21 2019-09-24
You can either clone a single node without descending nodes or a subtree.
On your example it looks like you cloned a subtree, and so changes on one subtree (removing node named g) are replicated on the other.
If you delete node d, it does not change the structure of the cloned subtree. Therefore node d can be removed independently.
The problem is the line
in the mm file. Instead it must be
No matter what particular sequence @robertonisola carried out to create his map, the result seems incorrect to me: as there seems to be only 1 (twin clone) instance of "g" , it must not have a square clone symbol but a rectangular one.
I think we all agree that node "d" is a child of node "m", right? You can check this in the mm file.
Also it is obvious that a clone of node "d" is a child of node "c", or am I wrong?
As far as I understood everything that happens to node "d" or its children has to happen also to "d" node's clone.
Now simply create a new child of any of the grand-children "g" of "m" or of "c". Bang! It will not be cloned to its twin "g".
deleted
Last edit: echo21 2019-09-23
deleted
Last edit: echo21 2019-09-23
@dpolivaev
Honestly I don't remember how I created that map. The map I attached here is just a strip-down version of the full map on which I noticed this behaviour.
In order for you to fully understand my concern, I'd like to tell you my way of using clones: I often create a lot of clones when working on a project. And when this project finishes, I delete all of the clones, but I have to keep the original node.
So regarding the 'strange' behaviour I mentioned in this topic, it is dangerous to me because up until now, whenever I see a clone with a large rectangle at its left side, I assume this node can be safely deleted. And by 'safely' I mean there is still at least one node else where in the map containing the same information as the deleted node.
But in the case with node g above, I cannot safely delete g because doing so will cause all of other g(s) disappear as well.
So my ultimate question is, if I cannot rely on the large rectangle as an indicator of a cloned node, then how can I know if the node can be safely deleted? Thank you.
@robertonisola this seems to me a very complex freeplane issue. It is very helpful that you provided the map. This demonstrates the existence of invalid mm files. But I fear that this is not enough for the freeplane devs. To find and fix the issue they would IMHO need to have a method how to reproduce the creation of such an invalid mm file.
Last edit: echo21 2019-09-24
@echo21: Thank you very much for your analysis.
The original map (which had this problem) was created and edited purely in Freeplane, using only mouse and keyboard, no script involved.
And I agree with you that it might be difficult to reproduce this problem because that map was very big with thousands of nodes, and thousands of commands (create, cut, copy, clone...) have been executed on it, and somehow a rare combination of these commands created this problem.
After all, no app is perfect so it is not uncommon for us users to encounter this kind of problems, even in Microsoft or Google products.
And, although this problem is not trivial to me, Freeplane still remains my number one mindmap app, and I will definitely continue to use it in the future. Big thanks from me to @dpolivaev and the other devs.
I just hope that one day the root cause of this problem will be found and fixed. In the mean time I will try my best to backup my maps as frequently as possible.