DOT/GraphViz [1] is very powerful. You might find it a bit unwieldy at first but, as with everything, editing in plain text is often faster than trying to use a GUI.<p>For extremely simple stuff, you can use TGF [2] to represent the graph and something like yEd [3] to view it.<p>None of these tools have any real provision for structured proofs etc., but that could be built.<p>[1] <a href="http://www.graphviz.org/Documentation/dotguide.pdf" rel="nofollow">http://www.graphviz.org/Documentation/dotguide.pdf</a><p>[2] <a href="http://docs.yworks.com/yfiles/doc/developers-guide/tgf.html" rel="nofollow">http://docs.yworks.com/yfiles/doc/developers-guide/tgf.html</a><p>[3] <a href="http://www.yworks.com/en/products_yed_about.html" rel="nofollow">http://www.yworks.com/en/products_yed_about.html</a>
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.
In the comments in the article somebody mentioned this:<p><a href="http://strlen.com/treesheets/" rel="nofollow">http://strlen.com/treesheets/</a><p>Looks really cool. I always felt spreadsheets were too grid-oriented and flow charts too much about vectors and nodes. Treesheets looks like a great mashup of those two.
Some others have already mentioned that "mind mapping" software is similar, and I'd agree -- just see this image[2]. That image was created with Mindnode[1], which I really like (I've only tried the light version, but that seems to be discontinued).<p>[1]: <a href="https://mindnode.com/assets/images/screens/iphone-1-1136x640-withstatusbar.png" rel="nofollow">https://mindnode.com/assets/images/screens/iphone-1-1136x640...</a><p>[2]: <a href="https://mindnode.com/" rel="nofollow">https://mindnode.com/</a>
Just slightly away from the practical job of finding a usable editor, but I found the following demo of an in-game node-based tree display/editing interface from Limit Theory[1] lone developer Josh Parnell quite impressive as eye candy if nothing else:<p><pre><code> http://www.youtube.com/watch?v=Ekq56VZqQvs&t=5m25s
</code></pre>
earlier version:<p><pre><code> http://www.youtube.com/watch?v=KN3tKT0E0t8&t=14m30s
</code></pre>
(EDIT: also at: <a href="http://www.youtube.com/watch?v=KN3tKT0E0t8&t=19m40s" rel="nofollow">http://www.youtube.com/watch?v=KN3tKT0E0t8&t=19m40s</a> as he updates the layout algo in real time (!))<p>Worth watching as he puts it through its paces.<p>If I was hiring someone to create a generic tree editor, his number would be top of my call list :)<p>[1] <a href="http://ltheory.com/" rel="nofollow">http://ltheory.com/</a>
I think there are many of examples out there; the simplistic answer to the OP question is "we do; you just haven't heard of them."<p>My favorite is OmniGraffle... you can enter nodes in a text-entry outline style mode and the results are updated instantly. The default styles and stencils, while recognizable as being generated by OG, are inoffensive, and the layout tools are among the best of any layout or presentation software.<p>Others have mentioned GraphViz, which is a general purpose graph description utility.<p>Outliners as a general category of software have existed since the 1980s and seen an ebb and flow of popularity. Just a few off the time of my head... Think, More, Acta, OmniOutliner.<p>The Frontier scripting language in particular stands out as a programming environment completely integrated into an outliner paradigm. My first exposure to code folding came when discovering Frontier sometime in the mid-'90s. As Apple put its Mac scripting focus on Applescript, Userland reimagined Frontier as a web site programming environment: templating, scripting, and content management all rolled into one. But at the same time it was a general purpose scripting environment.<p>Maybe my graphing needs are not so deep that these tools (or some combination with a few others) wouldn't suffice for a variety of tree/graph related tasks.
The author's examples -- proofs and ASTs -- provide a hint at the reason.<p>If you need a tree, it's most likely that you want some custom operations on that tree (e.g. parsing text into the tree, pretty-printing the tree, traversing the tree in various ways, etc.)<p>At some point, the tree is just a data structure and what you're interested in are full-blown, non-trivial algorithms/programs for fairly domain-specific tasks. In these cases, a library (or even custom implementation) for a general purpose programming language is more useful than a tool (a la Excel or vim).<p>Viewed in this light, it's not unsurprising that we have many domain-specific tools for manipulating trees. Most of the proof assistants have a GUI based on Gentzen-style sequents.<p>LaTeX has styles for type setting proofs which look like the ASCII ones in the article.<p>Tools for generating parsers often have tree-based UI's.<p>And so on.
Well, if you're okay with XML there's Microsoft's XML Notepad. It's xsd-aware so you get type-safe constrained tree editing. But it's ms, XML, and xsd...that's like 3 strikes.
I posted this on the blog itself, but re-mentioning it here... I've been evolving Xiki for over 10 years to do be a language for doing this kind of thing. The ideas is you can interact with trees and other nested structures (file paths, dbs, general UI's) from your text editor, using a simple plaintext representation, but in a GUI-like manner.<p>I've done talks about Xiki at RubyConf, Strange Loop, and QCon. Here's a quick 3 minute video - <a href="https://www.youtube.com/watch?v=bUR_eUVcABg" rel="nofollow">https://www.youtube.com/watch?v=bUR_eUVcABg</a>. I'm doing a Kickstarter campaign soon, to bring Xiki support to vim, sublime, and possibly other text editors!
You already have fairly general-purpose tree editing right under your nose - look at GUIs for your filesystem.<p>You can drag and drop folders and files. You can see the hierarchy on one side of your screen, and then the contents of a single node on another. Minimizing/expanding usually works. You can rename things in-place.<p>If you're imagining tree structures that don't map really well to this kind of GUI, then the reason your tree editor doesn't exist should be apparent.
I once wrote an ASCII graph/tree compiler that compiles ASCII representations like the example in the article into data structures.<p><a href="https://github.com/mgraczyk/GraphCompiler" rel="nofollow">https://github.com/mgraczyk/GraphCompiler</a><p>The data structures can be used directly in Python or parsed/consumed elsewhere. I think it is pretty useful, and I have used it in a couple of places where moderately complicated trees are used to generate C/C++ code.
Internally, we have a graph editing tool which uses D3 (screenshot [1]) which I threw together based on some existing examples. I'd be happy to open up the source code if there was any interest, though it's really nothing all that special. The layout algorithm could definitely use some work for our use-case at least. It's force-directed at the moment, using stock D3 layouts, but really needs a hierarchical mode. While it's not perfect, it is intuitive enough that non-technical people "get it".<p>Beyond this, yEd[2] is really quite cool (even if it does have a very dated UI).<p>[1] <a href="https://www.evernote.com/shard/s3/sh/67c67a48-8b3d-4eac-b7ee-427fbf6fb5ca/ab7dff4c05a5503d06b001ac7f248451/deep/0/Define-concept-relationships.png" rel="nofollow">https://www.evernote.com/shard/s3/sh/67c67a48-8b3d-4eac-b7ee...</a><p>[2] <a href="http://www.yworks.com/en/products_yed_about.html" rel="nofollow">http://www.yworks.com/en/products_yed_about.html</a>
Actually we have a lot of such editors. For example, JetBrains, MPS (<a href="http://www.jetbrains.com/mps/" rel="nofollow">http://www.jetbrains.com/mps/</a>)<p>I am currently working on a web based version of such an editor at JetBrains. You can take a look at it here: <a href="http://jb-proj-demo.appspot.com/" rel="nofollow">http://jb-proj-demo.appspot.com/</a> (It's open source and it's available on github here: <a href="https://github.com/JetBrains/jetpad-projectional" rel="nofollow">https://github.com/JetBrains/jetpad-projectional</a>)
I am surprised that nobody has mentioned Tinderbox. It is an awesome mindmapping/outlining application and one of the two applications that make me jealous of OSX users. (Bibdesk is the other)<p><a href="http://www.eastgate.com/Tinderbox/" rel="nofollow">http://www.eastgate.com/Tinderbox/</a>
Productivity problem because of degrees of freedom.<p>Hard to do without graphics, and once you introduce graphics, you end up with endless non-productive futzing by non-graphics artists trying to be amateur graphics artists with move this one pixel over to get an artistic look or whatever other graphical effect. Unfortunately the user isn't a graphics artist and is theoretically hired to write code or memos or reviews, so they're both working way out of their core competency AND usually not any good at graphics arts. And if you don't allow hours of futzing, a competitor will, and you'll be destroyed in the marketplace. People like futzing even if its by definition totally anti-productive, which isn't all that weird given the popularity of the open plan office and so on.<p>Nothing is ever new in IT. In the early years of desktop publishing, productivity suffered dramatically because a simple memo meeting notice which took 10 minutes on typewriter and xerox, now took at least 3 hours of font selection (at least 6 different fonts and sizes per page) and endless clip art and at least 10 revisions to get it "just right".
The author might be looking for Treesheets: <a href="http://strlen.com/treesheets/" rel="nofollow">http://strlen.com/treesheets/</a>
It's been a few years since I've played with it, but Leo[1] seems like it might be what the author is looking for. It's even scriptable (in Python). Looks like it is actively maintained[2].<p><a href="http://leoeditor.com/" rel="nofollow">http://leoeditor.com/</a><p><a href="https://github.com/leo-editor/leo-editor" rel="nofollow">https://github.com/leo-editor/leo-editor</a>
I created GraphBin (<a href="http://graphbin.co" rel="nofollow">http://graphbin.co</a>) because my data structures and algorithms prof didn't want us to hand draw graphs for assignments. I didn't want to make them via paint either.<p>Maybe not a general purpose tree editor, but at least it's helped me out so far :)
For general purpose graphical tree editing a tool like yED [1] might be the most flexible solution. yED's native GraphML can be easily transformed into other XML-like Structures.<p>If you like a plain text solution the TGF Format might suit your needs. It can also be visualized and edited in yED but it's very limited in its feature set.<p>A very nice and simple solution for visualization of small trees is to parse plain text with XSLT and transform it into SVG [2].<p>For are more programmable concept i would recommend to have a look at the combination of D3js [3] + JSON (or XML).<p>[1] <a href="http://www.yworks.com/en/products_yed_about.html" rel="nofollow">http://www.yworks.com/en/products_yed_about.html</a>
[2] <a href="http://www.xml.com/lpt/a/1472" rel="nofollow">http://www.xml.com/lpt/a/1472</a>
[3] <a href="http://d3js.org" rel="nofollow">http://d3js.org</a>
We have file tree viewers, and standard GUI components like Java's JTree.<p>I only skimmed, but the article didn't seem to address the questions raised ("why?"), but instead described the problem and proposed solutions.<p>I think an answer to the question would be far more interesting and revealing... it might simply be that 1. it's hard; and 2. text is far better at hierarchical structures. Like his examples, lisp, programming languages in general, arithmetic algebra.<p>So I think the hint is that the Human Processing System is adapted to handling hierarchical structures linguistically (i.e. symbolically: speech, writing, text). I suspect there is a very good and deep reason for this, to do with the kinds of operations (transformations) typically needed. But I don't know what that reason is.
Might be more fruitful to think of a graph or tree "ecosystem" rather than just an editor. For an ecosystem one can think of the following aspects:<p>- a representation that can be shared by various tools, possibly in parallel. Allow attaching arbitrary attributes<p>- ability to map between equivalent but different representations (adjacency matrix, node/link/port etc.)<p>- plugins that operate on a specific rep. and map to some visual representation<p>- a language for programmatic construction (or may be a library)<p>- efficient storage representation (one or more)<p>- communication protocol for sharing/moving subgraphs<p>- key/mouse bindings when viewed graphically<p>- macros/functions to encapsulate useful patterns<p>- graph manipulation & mapping tools (e.g. mapping a circuit schematic to a PCB, compiling, etc.)<p>[Sorry for the frequent editing - I was trying to get the list right. Still not quite right.]
Another project related to the one propossed in this article is a diff-diff3-patch like program suite that can be used on trees. It would fit in a great way with version control systems and make them (more) aware of structural changes in changesets.<p>Imagine being able to dump plain-text files for real trees when diffing-merging. The way differences are shown to the user could be like a project i did a few years ago to show differences in graphs (applied to basic-blocks graphs). Here is the link: <a href="http://corelabs.coresecurity.com/index.php?module=Wiki&action=view&type=tool&name=aureliax" rel="nofollow">http://corelabs.coresecurity.com/index.php?module=Wiki&actio...</a>
I use treeline.<p><a href="http://sourceforge.net/projects/treeline/" rel="nofollow">http://sourceforge.net/projects/treeline/</a>
Hm... I've been quite happy using an Open Source tool called FreeMind. It seems to be a "tree editor", although I'm not sure it quite satisfies what this author is looking for.<p>Screenshot: <a href="http://freemind.sourceforge.net/wiki/index.php/File:FreeMind-computer-knowledge-080.png" rel="nofollow">http://freemind.sourceforge.net/wiki/index.php/File:FreeMind...</a><p>Website: <a href="http://freemind.sourceforge.net/wiki/index.php/Main_Page" rel="nofollow">http://freemind.sourceforge.net/wiki/index.php/Main_Page</a>
The problem is that everybody has different goals in a tree editor. But the Sony ATF framework, has a lot of support for graph editing.<p><a href="https://github.com/SonyWWS/ATF" rel="nofollow">https://github.com/SonyWWS/ATF</a><p>See many examples in the gallery: <a href="https://github.com/SonyWWS/ATF/wiki/ATF-Gallery" rel="nofollow">https://github.com/SonyWWS/ATF/wiki/ATF-Gallery</a>
You say things like "programming languages have an AST", but in reality, it is more like a couple of directed graphs over an AST in terms of the semantics. The AST is more an accident of how we compile, but syntax is still invalid if you fail to match types, which are context sensitive; all of the calls (and thus most of the meaning of a function) refers to these tables as well, and many nodes can share the same "semantics" subnode; and by far the most important part to us as while programming is the data flow, which is structured as an often cyclic directed graph. Really, the tree does not buy us much of anything in this case: modern editors tend to allow syntax aware edits and refactoring anyways, and coding structure dictates that your code "look" like the AST anyways with blocks and spacing and such.<p>Similarly, proofs are only treelike at a very small depth before becoming directed graphs, and most modern data stores like XML and JSON which form trees tend to have additional logical (if not formal) schemas that add complexity to the problem.
Ashton Tate made a tree editor called [Framework](<a href="http://en.wikipedia.org/wiki/Ashton-Tate#Framework" rel="nofollow">http://en.wikipedia.org/wiki/Ashton-Tate#Framework</a>) which I used to write my thesis in the late 80s on a DOS machine. I loved it. It had intuitive keystrokes, using the numeric keypad to zoom in (+) and out (-) of the tree with an easy way to collapse the tree branches (enter).<p>Each frame held other frames, or could hold text, a spreadsheet or a database.<p>It wasn’t a DAG (directed acyclic graph) which was frustrating sometimes.<p>I think you could program leaves to link to other leaves, but I wasn’t any good at programming. It had its own programming language FRED.<p>The people who grokked it loved it.<p>I think there is still a [closed source](<a href="http://www.framework.com/" rel="nofollow">http://www.framework.com/</a>) community supporting it, last time I looked.<p>I hope you will use markup with something like YAML or [JSON-LD](<a href="http://manu.sporny.org/2014/json-ld-origins-2/" rel="nofollow">http://manu.sporny.org/2014/json-ld-origins-2/</a>) to store your links.
This is pretty much exactly what we're trying to achieve with Gingko.<p>It's a full tree editor, that is being used for everything from PhD theses, to television screenplays.<p><a href="http://gingkoapp.com" rel="nofollow">http://gingkoapp.com</a>
<a href="https://www.youtube.com/watch?v=egCKZHsICm8" rel="nofollow">https://www.youtube.com/watch?v=egCKZHsICm8</a>
I think text editors are a bad comparison because they do something a little different. They are not linked to a specific data structure, they are linked to a particular data type. All of the examples of how diverse text editors are (Latex, csv files, log files, etc) are completely different data structures but all are stored in the same data type -- plain text. You can easily edit tree data in text files as long as they are stored in a plain text encoding. Counterpart to text editors would be hex editors, and all of the above can be done in them if the original data was stored in a binary format.<p>Text editors are useful because standards have evolved with them. We have standards for trees - XML and JSON for example. CSV editors are useful because there are ways to convert other table data into CSV to work with. If you just allowed a tree editor like XCode's plist editor to import other file types it would be the same situation.
I said I was jut going to ignore this downthread, but I just can't help myself. Feel free to dismiss it as "another emacs dweeb pointing out they've been using alien technology since the 1970s".<p><a href="http://orgmode.org/manual/Structure-editing.html" rel="nofollow">http://orgmode.org/manual/Structure-editing.html</a>
I'm definitely thinking of making a graph based text editor.<p>I think I could work off of code-highlighting files to figure out where to break code out into different nodes.<p>Then, I would look for matching terms in each node, and make connections. Connections could also be made based on containment (part of a class, or a child function, or a where clause).<p>One hotkey to follow a connection to it's destination (and select that node). Another to pull it in and make it share the screen with the current node (and select it). Pressing the "pull in" key would push a node off the screen if it were already on screen.<p>Of course, maybe you would only want to explode some of your code as nodes. You could highlight part of you file and hit "explode" to break it out into nodes for a minute.
I'm writing one. Inspiration from <a href="http://www.treepad.com/" rel="nofollow">http://www.treepad.com/</a>
I use Treepad for notes heavily. Now I want to be able to manipulate the tree programmatically.<p>Also it will serve for a html/js workshop for kids. They have a hard time setting up and working with regular editors and the file system.<p>The program is general purpose (different kind of node can be handled with plugged-in "drivers").<p>If you're interested, drop me a mail.
It's ugly, but take a look at the HDF editor:<p><a href="http://www.hdfgroup.org/products/java/hdfview/" rel="nofollow">http://www.hdfgroup.org/products/java/hdfview/</a><p>There's also:<p><a href="http://oboedit.org/" rel="nofollow">http://oboedit.org/</a><p>The deficiencies in the generally available tools are obvious, but refined versions do exist here and there.
I use a tree editor[1] in one of my products, it's almost a graphical DSL, originally inspired by a now deceased product called FormScape.<p>[1]: <a href="http://www.folderagent.com/images/blog/fa-rules-tree.png" rel="nofollow">http://www.folderagent.com/images/blog/fa-rules-tree.png</a>
For this purpose I like typing out YAML files in Sublime Text 2. It has syntax highlighting and a formatting plugin. YAML is much more concise and readable than XML and JSON, and many programming languages have libraries for parsing and deserializing it into an in-memory object.
I've actually looked into the existence of quality JSON-editing tools that can deal with more than 2 dimensions and have not found anything good yet. Too bad, because excel/csv can be pretty restrictive for certain types of data.
Have you seen Tom Sawyer software? components such as <a href="https://www.tomsawyer.com/products/layout/index.php" rel="nofollow">https://www.tomsawyer.com/products/layout/index.php</a> (commercial).
What I'm looking for is a code editor that doesn't let you edit text but rather the code tree. That prevents you from writing a code that is not a valid tree but doesn't get in the way too much.
Well, I used to develop MindVisualizer (<a href="http://innovationgear.com/mind-mapping-software/" rel="nofollow">http://innovationgear.com/mind-mapping-software/</a>)
I have this crazy idea in the back of my mind to write a visual programming language based on Haskell, where shape and colour convey kind and type information. Still cooking that one.
Freemind might be similar to what you're looking for.<p><a href="http://freemind.sourceforge.net/wiki/" rel="nofollow">http://freemind.sourceforge.net/wiki/</a>
nestgrid is a general purpose tree editor. Description, in-browser flash demo and desktop app installer are available at <a href="http://nestgrid.org" rel="nofollow">http://nestgrid.org</a><p>ETA: incidentally, architecturally it is structured for easy plugin / "script" extensibility, like a low key emacs.