Freeplane - Split mindmap.

[StoltHD]

You wanted me to also replay here, so here is my little explanation on how I split my mind maps into notes...

---

My Freeplane Hierarchy is made so that I can use the Headers as folder names, e.g. those Nodes that only have a name, but no other text or content is folders, if a Node have content in addition, it will become a Note in addition.

e.g. I have a Node named "Person" (no additional content), under that Node I have a Node "John Smith" with additional content (metadata like "birth year:" or "phnoe Number:" ), then the folder structure would be: Person (folder)

• • Smith John (b. 1922)
• • • [Note name: Smith John (b. 1922).md]

In that note I would have metadata, text, links etc.

At the moment I had to do this semi-manually, via Scrivener and some cut and paste to get it right...

---

Alternatively it could be a script with a few variables where you could set what levels that would be Folders and what levels that would be Notes. Let say you had one variable with how many levels (maybe it can be read by a script, I don't know), and then you create that amount of variables with a single flag, e.g. L1=F (folder), L2= folder, L2x= (note, x for extended note, e.g. note with content not only name), that way there wouldn't be any problem with the amount of levels and if the user set 0 as number of levels, only Notes would be created from the Nodes. It would be up to the user to create or change his Freeplane Hierarchy if he wanted to use this.

A big warning would be necessary, to warn users that on Windows they would need to enable 32-bit file path if they had many levels and long Node Names.

---

Hopefully it is understandable

[OliverCi]

Yes, this looks like a use case, that also others might have in a similar way.

Together with the already existing leveling of headers and list items, this would then give in total four layers of how nodes are converted:

1. Separate folders
2. Separate files
3. Markdown Headers
4. List items (or nested todos)

Assuming, that these are always strictly nested in the above order, I could imagine command line options similar to the already existing -l / --headerlevel, e.g. --splitfolderlevel and --splitfilelevel denoting the number of levels to be split into folders or files respectively. Both new options would then simply default to zero.

Since other users might have additional content (text) directly at or under the levels being split into folders or files, we have to handle this case as well. This text could go into Markdown files containing (wiki) links to the Markdown files containing in turn the converted sub-notes. (Let's call the former "branching files" in the following.)

I currently see the following options to decide if or how to create branching files:

1. Always generate them. (If not needed, the user can simply delete them.)
2. (A) command line option(s) to let the user explicitely decide.
3. Analyse, whether the nodes converted to folders or above split files directly contain text in addition to sub-notes. Only create corresponding Markdown files, if this is the case.

It appears to me, that for the beginning, the option 1. may be the easiest and safest.

Obviously, icons or links directly contained in headers converted to directories cannot be preserved - or they as well would have to go into the branching files. (For split files, it might be sufficient to put them into the a header within these files.)

Your remark with the windows path length is a good one - it might even become a sanity check within the script.