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

I'm not being facetious here ... but aren't XML, Json and Yaml popular tree-structured formats?

Like OP mentions Excel for instance, for editing tabular data, which isn't quite a standard file format, and in any case supports many different formats for tabular data.

I can't help but wonder if OP is focusing on "format" rather than the structure of the data itself. There's plenty of editors for these well known formats. Perhaps he just needs to restructure his problem to use one of these?

In XML for instance, it's fairly straightforward to implement a "plugin" such as he describes, using python or ruby and a DOM parser, which could amongst other things provide the different renderings described.

I remember using XML Spy a long time back which seemed to do this quite well, as an ever expanding grid of cells, click into a cell, and it would expand showing its constituent cells. There were different tree representations available as well.

> regularly edit large equations in LaTeX. I don't see how it's not manageable, just break your equations into multiple lines.

I understand how to indent TeX, but when you have a hundred algebraic terms it's very unwieldly, and Mathematica becomes clearly superior (for me) just to visualize it.

Anyways, it sounds like you're just saying you haven't found the graphical visualization for equation trees to be useful, so you stick with the linear representation, but the manipulations of those trees (by mathematica, or some other dedicated editor) is still useful.

In this case I would add that we would probably still need some sort of visualization aid for sufficiently large equations, and that the tools are just not good right now. After all, much/most code is written in normal (linear) text editors, but some people still do find it useful to "collapse" sections of code, corresponding to branches of the tree structure induced by indentation. Many people don't bother with this right now because it can cause headaches that simple scrolling does not, but better tools may change this.

The third screenshot [here][1] is hilarious :)

[1]: http://strlen.com/treesheets/docs/screenshots.html

Pretty good, it almost make you feel you're working on trees and not text. Takes a few moments to get used to. I recommend what I did: take a bunch of Lisp code, strip it out of parenthesis (M-x replace-string, replace ( and ) with empty strings), and then use Paredit commands to restore the original tree structure. I spent less than an hour simply doing this exercise again and again, and it was enough to become a proficient user.

I've been thinking about this constantly for the last 2-3 years. I'm working on something which might lead to this.

What I've concluded, is that we don't have a good representation for a general purpose tree editor to work on. Roughly speaking, S-expressions are just a bit too simple, and XML is way too complicated.

General purpose plain text editors work so well because we've agreed on a common representation (more or less), which is easy for text. But as soon as you want to move to useful, common tree-structures, you have to agree on both representation and semantics, which makes it much harder.

One challenge we need to solve is - what level do you want to work on? Let's say you're working on some code. You may want to treat functions and blocks as a tree structure, but you want to treat simple mathematical expressions as text. Where this threshold is, is entirely context-dependent. The editor needs to understand the language and be able to expand text into its tree structure, or collapse the tree into its text representation, at any node in the tree.

This implies that we need to agree on a common format for defining the conversion (parsing and generating) between text and trees. We'd probably also need a package system which contains common definitions for all major languages.