Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

merge nodes #4

Open
JeffreyBenjaminBrown opened this issue Aug 2, 2016 · 3 comments
Open

merge nodes #4

JeffreyBenjaminBrown opened this issue Aug 2, 2016 · 3 comments

Comments

@JeffreyBenjaminBrown
Copy link
Member

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.

@joshsh
Copy link
Member

joshsh commented Aug 3, 2016

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.

1 similar comment
@joshsh
Copy link
Member

joshsh commented Aug 3, 2016

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.

@JeffreyBenjaminBrown
Copy link
Member Author

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 ...)

@joshsh joshsh changed the title Feature: Merge nodes merge nodes Aug 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants