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

There have been pure S-expression editors in LISP. INTERLISP worked that way. Yet EMACS, which is a text editor which knows a little about S-expressions, won out. INTERLISP's LISP editor had features never seen since, such as "Make this code subexpression a standalone function". This would pull the subexpression out and make it a named function, inserting the correct calls with the correct arguments in the original code. The inverse operation, "expand this function here", was also available. This eased refactoring.

There don't seem to be tree-oriented editors for XML. Or HTML. Or even JSON. That would be useful. At least the tree structure would always be correct. More effort is going into figuring out how to parse "bad JSON" than into writing editors for it.

"old school PIM"? Wikipedia and I find this ambiguous [1].

1. https://en.wikipedia.org/wiki/PIM

This doesn't sound like a difficult macro/function to write. More, this has been replicated in other languages, now. These refactoring capabilities are considered a hallmark of the popular IDEs that people point to.

And keeping HTML "well formed" is a battle that lost hard with xhtml. Further, any "rich" editor likely kept the tree structure well formed. It did little to keep it manageable, though.

And I wager that most "bad JSON" is programmatically generated. This is literally a problem with countless solutions today. But, it is almost always quicker to println something out that you are certain you know the structure of, than it is to use a library. So, people don't. :(

I second this.

I'm using yEd a lot, and I especially like layouting functions like hierarchical layout. I often use it to plan interdependent tasks. I just start with tasks I know are required and the thing of their prerequisites. Quite fast this gives a big graph structure. Then I run a hierarchical layout on this and suddenly I have a very clear structure of tasks. Their hierarchical layouting algorithm is great. I suspect it may be based on GraphViz dot's algorithm (http://www.graphviz.org/Documentation/TSE93.pdf) as it produces results of similar high quality.

I also love the UI of yEd. Zooming in and out, creating nodes and dependencies/edges feels just great.

The key insight of this post for me is this: Code editing is tree editing! The reason why code is edited in text editors, is that tree editing interfaces are fundamentally difficult to do well, and often have to be carefully tuned to the properties of the particular trees and editing tasks. (Simple examples: Huge fanout vs. at most 2 children. Very large information-rich nodes vs. tiny nodes.)

In the early days of programming text editors, we dealt with this difficulty by exploiting the human brain's mechanisms for dealing with serialized trees -- which is to say the human brain's facilities for processing language and reading and writing text. By doing this, we could represent all kinds of hierarchically structured code, and let the human brain process it. But even in these early days, we started bringing in visual aids for reading structure: indentation and braces.

Now, if you look at modern IDEs, you'll find even more geometric/visual representation of the tree structure of code, in the form of collapsible tree controls operating on the code. This isn't to naively say that graphical programming is the way to go, since the potential for interrelation and complexity of structure in code is far too high to comfortably represent in 2 or even 3 dimensions. The way forward is to be able to dynamically visualize very specific contexts. (One example I can think of of the top of my head, would be to quickly visualize all "subscribers" of an Observer, then be able to visualize the 2nd order "users" of those subscribers. Another would be to visualize patterns in code supporting dataflows as an explicit flow graph.)