Why Don't We Have a General-Purpose Tree Editor? (2014)

One huge question to ask is why you need an editor specifically for a tree. Do you want a gui, or a format? If you need a gui, you are automatically in domain-specific territory. If you only need a format, maybe you don't need a tree editor at all.

Excel is a great tool for making trees; just add a column that names your parent. I used Excel to create a prototype of an event driven animation sequencing engine for a Disney game. It was more of a state machine / directed graph than a tree, but the only constraint there is data, not the editor. The prototype was later replaced (after the game using Excel shipped) with a gui based tree editor, but not something that could be called "general purpose".

I've long thought that hierarchical file formats come with some pretty bad downsides, from both sides, usage and implementation. You don't need a hierarchical format as long as you are willing to name all nodes and not allow anonymous nodes. Once you do that, you can have a flat file structure with fields that reference other nodes. Once you do that, XML feels crazy. Easier to implement parsers that don't have to do overblown amounts of dynamic memory allocation, easier for humans to read & follow, easier to share references or allow non-tree structures, etc. etc.

For the programming use case there is also Leo.

http://leoeditor.com/

Leo is of particular interest because it automatically syncs between the tree and code files: http://leoeditor.com/tutorial-programming.html

The approach is documented here: http://leoeditor.com/appendices.html#the-mulder-ream-update-...

Because the use case of "edit all graphs" is too divergent to be solved by one program.

For simplicity, let me start with just trees. What kind of trees have we got?

Well, we've got programming language ASTs. In these trees, nodes tend to have only two or three children, each of which is probably a short word or a number, but they can easily extend hundreds of levels deep, or even thousands. (Before you disagree with this, go take a look at the dump of the AST of a modestly complicated Python function or something. Many programming language grammars are not optimized for this representation and end up with way more intermediate grammar nodes than you'd expect, which all seem like they'd be really easy to "just" collapse, but that causes its own problems.) The naive and obvious representations of all of this are difficult to navigate and consume the vast majority of the screen with whitespace. It rapidly becomes clear you need a specialized mechanism for dealing with this... then after a few iterations, if you do it right, you discover that you've reinvented... the original textual representation.

(This is not proof that textual representation is optimal in general. You can correctly argue that you end up there because the entire language was designed with that in mind in the first place, and that a language designed to be graph-based in the first place may work better. However, your tree viewer doesn't have any of the latter that doesn't already have a special-purpose viewer built for it, which your putatively generic code isn't going to compete with.)

Database rows are just a graph, right? Well, that's one top-level node for the result that contains the rows, and then, oh, let's say 25,000 identically-structured children. How are you going to navigate that? Are you going to introduce a "paging" concept? If so, you're going to complicate the other uses of this generic editor that don't need it.

How about rich text? Rich text is just a tree. But is your generic tree editor going to require sub nodes for "bold"? For that matter, how does your generic editor handle either of "text bold more text" or "text span more text"? There's a lot of different rules that people may want to apply to tree nodes; do those look like one, two, or three nodes in your editor? I can make a case for all three, for instance, for the first one (imagine the word bold is bold in the first one, it's a rich text display):

     * text bold more text

     * text
       (bold) bold
       more text

     * text
       (bold) bold
     * more text

(Note the new asterisk on the third line of the last one; it's a new node. In the first one, we have "special" nodes that can be embedded, whereas others probably can't be; that's a heck of a concept to write into your generic editor and will have huge ramifications in all sorts of other places, not least of which is the graph data representation and API. In the second one we somehow have "embedded" nodes, which has the same problems, except it has different massive effects on the graph data structure and API. The third is conceptually simplest in a lot of ways, but maps neither to HTML nor to the human's internal representation very well.) Now, how do your choices that you made for this rich text application map back to the other types of graphs you may want to support? Because each of those three choices will have different implications if you then try to support RDF graphs in the same visual layout.

Speaking of RDF... have you considered the visual differences between ordered trees and unordered trees? Box & line graphs naturally represent unordered children, outline views impose a view of order even if one doesn't exist, other layouts may have other consequences. You can't just let the decision about outline vs. box & line be determined by the orderedness of the nodes either, because there may be other properties of the graph that may be unsuitable for.

And then, of course, there's the graphs that you want to view as box & line diagrams, the ones you want to have fully manual layout for vs. the ones you want some degree of automation. And you've to deal with the boxes that are way too big for the display because they contain several dozen kilobytes of plain text. Can your boxes contain subgraphs within them? And under any display methodology (graphs, outlines, whatever), what does it look like when you have a node with 25,000 incoming links? Does that work well with graphs that have only a few nodes like that? What about graphs like friend networks on Facebook that consist almost entirely of nodes that have hundreds of links? Note that when you've seen graphs of Facebook, they never much resemble, say, LabView diagrams, they're always these very zoomed-out representations with only entire regions colored and being discussed. How is your generic graph editor suitable for use on programming languages doing with this graph?

The theme here is not "unsolvable problem". The theme here is "unresolvable conflicts between different use cases". In an individual context, these issues are solvable, and have been reasonably solved. But trying to create a generic "graph" editor is, well, given the genericness of the term "graph" basically trying to create a generic "editor".

Isn't that called Outliner?