We do not have a general purpose tree editor because trees are quite the complicated structure, and most valuable operations on trees require quite a bit of knowledge of what the tree represents.<p>Look at, for instance, source code. In many languages, we represent code in a tree-like structure, just with text and braces/parenthesis/tabs as indentations. But we all know that there are major limitations on how to represent a class. If you have 200 methods in a class, said class is unwieldy. If your methods are very deep, the whole thing also becomes unwieldy, so we make them smaller. We'd still do that with huge monitors that could show lots and lots of code at once: Without abstraction, any nested structure is hard to manage.<p>Many text editors will collapse levels for you, but really, how often do you all use them? Whenever you need to use them, it's a smell, because it means that the structure is getting too complex for a mind to handle.<p>This is not an issue that is unique to code. Any tree structure has the same issue of abstraction: We are not designed to handle more than one layer at a time, unless we are dealing with a tiny number of nodes. We have trouble seeing trees and navigating trees, so of course we can't have good general tree editors. I've seen four attempts at just general tree visualizers at work in the last year. The most successful barely pay lip service to regular tree 'views', and instead try to answer secondary questions that would help us know how we want to explore the tree.<p>And, as others here have already said, there's always non graphical representations. find, awk and grep can go very far when you are trying to find things on a tree. Proper indexing does a good job too.