Open JeffreyBenjaminBrown opened 8 years ago
Agreed. This is straightforward and useful, and should be done. In Emacs, perhaps the user copies two target references to the clipboard, then executes a merge command. The last two references copied define the merge. The only catch is that there is no automatic undo, and a manual undo would be difficult, so a prompt to confirm the merge (and choose between alternative property values if they exist) is probably appropriate.
Agreed. This is straightforward and useful, and should be done. In Emacs, perhaps the user copies two target references to the clipboard, then executes a merge command. The last two references copied define the merge. The only catch is that there is no automatic undo, and a manual undo would be difficult, so a prompt to confirm the merge (and choose between alternative property values if they exist) is probably appropriate.
The text of the nodes to be merged might also differ.
The operation wouldn't have to be destructive. A new edge type called "merged", and some higher order programming (so that the "show node" function used depends on the neighborhood of the node in question), could allow what looks like merging until the user has to explore an error. (This of course shifts work from the user to the coder ...)
A "merge nodes" function could be nice -- one such that nodes A and B with (respectively) children CA and CB and parents PA and PB become a single node A+B with parents PA+PB and children CA+CB. (Text and properties would have to come from one or the other, not both.)
Multiple Freeplane imports provide one motivation: The font nodes created in subsequent imports will need to be merged with the earlier ones.
A perhaps more common motivation would be when someone has taken notes under a topic named X in multiple places.