2. Organize General APIs

[pysan3]

3. Organize General APIs

Although neo-tree has a very extensible system with external sources, it is very unclear what the external modules should and shouldn't handle by themselves.
We should make a distinction between public and private API and we should add docs for at least the public facing functions.

[cseickel]

This is an organic growth thing. External sources were not part of the original design and just enough was added to make it possible, I think because of netman.

There are thre major areas of organization I think are needed:

1. External Sources: type would be a huge help here but also documentation. I'm not really sure there is much that I think about as "internal" with regards to external sources. The internal vs public API concept to me is more about end users utilizing these APIs in their configs which is impossible to know about. When it comes to external sources we can work with them to plan or any breaking changes. At least that is how I have thought about it up until now.
2. Setup/config: this whole things is just a huge tangled mess.
3. renderer.lua: this file is way too big and should probably be broken out into a whole module for window/buffer management that is easier to use. I think you partially address that in 3. Window Management Server / Client System #1337

[pysan3]

I now think we should deal with this later when 3~5 is implemented.

But while working with 3., I think I'll need to bring some kind of breaking change somewhere, so I kinda wanted to reorganize what and what not will bring a huge impact on the codebase and to external sources.

Maybe it'll be better to provide a how to migrate document for people making external sources listing the breaking changes.

[cseickel]

At the end of the day, I don't think there are that many methods in renderer.lua used by external sources. They are mostly called within that module, it's just messy. I think it will be an easy conversion and we can probably do it in stages, so the old methods just ask as wrappers to proxy that new methods during a transition period.

Also #1340