Another big limitation with Omni - it doesn't have a mode where it can just operate on and save to graphviz format. It's screaming out for this. Omni could be the editor of choice for graphviz. Instead they have gone down the route of allowing you to import what you want, but then you have to save it in their opaque format.
It seems like a good product, but it doesn't fit my requirements because (1) it doesn't support plugins to specialize its functionality to particular domains and (2) its reliance on the mouse looks like it would make it far too inefficient for the kind of work I would like to do.
It's an interesting project, though, I'll try to check it out and see what I can learn from it.
Workflowy has keyboard shortcuts for pretty much everything. I've been using it for about 6 months now and I swear by it.
Workflowy is an enlighteningly simple app (it's really just bullet lists with zooming) but it's incredibly effective for what it does, and the free-form nature of it makes it easy to just brain-dump random notes to get your thoughts out into text. I use it to do rubber ducking [1], because just the act of putting my problem into text helps me organize my thoughts. I can't say enough good things about it.
There's a screenshot and a live demo. Workflowy is more advanced and capable. I made my app solely to note down everything. I have been using it for 4 solid years now and it has helped me organize my life.
I am deeply fond of keyboard-driven browser-based outliner Checkvist (see description and screenshot at https://checkvist.com/auth/help). It's similar to Workflowy, and quite featureful. Like Workflowy, you can "zoom in" to a branch and only view it and it's children, which is very helpful when editing complicated outlines.
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.
Are any of them scriptable to the point where we could add our own desired functionality? Python preferred for me, but I'd learn another language if the app was compelling.
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.
Why the joking punctuation? With userspace filesystems it is easy to expose any tree like data as a filesystem. In fact, a while ago I made a (still readonly) filesystem for my browser bookmarks.
As long as I am on the topic of this, you know that you are in under explored territory where the first man page you visit for debugging your first non-trivial problem starts with "This is not the function you are interested in." (man getdents).
If you're not joking (and it is April 1), you seriously should check out nxml-mode for emacs. It has amazing support for RelaxNG based schema (the compact syntax).
I'm looking for more of a forms editor, that generates xml and guides editing with an xml schema. So no I don't want to edit xml; I want to edit data records, configuration file entries etc with a schema-driven editor.
We do. Have a google. Some are also mentioned in the comments. All major business tools have them (e.g. XMLSpy) - just not unix/lisp/hacker tools. May be why you haven't heard of them.
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.
For extremely simple stuff, you can use TGF [2] to represent the graph and something like yEd [3] to view it.
None of these tools have any real provision for structured proofs etc., but that could be built.
It's not that complex, actually. Here's how the basic usage works: you have a text file containing something like this for an undirected graph --
graph graphname {
a -- b -- c;
b -- d;
}
-- or like this for a directed graph (the -> arrows show you which direction the links are going):
digraph graphname {
a -> b -> c;
b -> d;
}
You can break up that first line into a -> b and b -> c and get the same graph if you want. It's not necessary here but it is when you have lots of outgoing links from the same node.
The other things you can type in are basically formatting options for the various utilities. You then feed these text files to various command line tools to do things like get a PNG of your graph:
dot -Tpng my_text_file.dot -o my_graph_image.png
That's it. The rest is just playing with it to get what you want.
Yeah, it's more the size of it that comes off as imposing at first. I was able to find a decent tutorial when I had to use it and went through the very basic usage of "make a graph and get a PNG with a few formatting options" but there's a lot more available if you have need of it.
I've made "proof graphs" with GraphViz, but honestly it was something of a challenge to make them look how I wanted them to. Compared to the time I spent drawing the graph on paper, (ie, collecting the statements and theorems), making the GraphViz version look okay took a long time.
Those graphs are good examples of what I want to be able to make. You bring up a critically important point, though: I must be able to write graphs very quickly, easily, and painlessly, like I use vim to write text or Trello for to-do lists. Most tree-editing interfaces are painfully inefficient and slow to use (and are far too reliant on the mouse).
Speaking as someone who has used graphvis before, those examples are one possible mode of output. The input for the graphvis programs are plain text files. See:
To be clear, the syntax I suggested in the article is what I want it to look like, not what I want to type in. It takes far too long to type most of those (except the lisp-style one).
I would like to be able to add nodes as easily as I add cards in Trello.
I wrote an iOS app around Graphviz called http://instaviz.com, you can create fairly sophisticated DOT files with shape sketching and linking and without delving into the underlying DOT language.
I don't think that qualifies as "commonly-accepted". It's not a bad format (for trees -- it doesn't look like it generalizes to DAGs or graphs), but a standard format might be helpful.
You could try Little Outliner[1]. Dave Winer has been making outliner software for decades[2]. I remember playing about with a desktop app years ago. I guess Fargo is the latest iteration.
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).
I'd never really seriously considered mind mapping software, and while I still don't think it's exactly what I want, it actually seems to have more potential than it seemed. Thanks for the suggestion.
For tree data you may want to look into various XML designers / editors. You can easily define a recursive XSL style sheet that has the structure you want, after that there are various editors that automatically read that structure and give you a GUI from it.
It's been a few years but I found XMLSpy to be fairly decent. http://www.altova.com/xmlspy.html
Edit: The simplest tree editor is probably the file system on your computer. However, the problem is for proof's I suspect your going to want to have some sort of graph structure.
PS: If your willing to do some light coding XQuery/XSL-FO let's you transform the raw XML into various more user friendly formats like PDF's. However, if your structure is really nested that quickly get's hard for people to understand.
The issue with a lot of mind-mapping software is that the data must be strictly hierarchical. Sometimes when brainstorming you want to represent data with cross-links or in multiple categories, which is where something like Graphviz, Instaviz, Omnigraffle or Visio come in.
Mind-mapping is useful, though I've yet to find a tool I really like and can use 1) intuitively and 2) for very large models.
Online, there's Text2MindMap[1] which is quick and easy to use, and offers a rubber-band like ability to reposition nodes, but in my experience, once past a couple of hundred nodes (I do some fairly large maps) performance gets really laggy, especially if you've got an otherwise populated Chrome session running.
Offline, there's the FreeMind[2] tool, Java based. My main problem with it is that editing is incredibly fussy.
What I prefer mostly is GraphViz[3], which is not just a mind-mapping tool, but can be used as such. The advantage here is that what you're editing is a simple text file, with graphic output created by running one of the graphviz commands over it (dot, neato, twopi, circo, fdp, sfdp). For a traditional mind map, the 'circo' command is probably what you're looking for. While not as interactive as other methods, if you're working on a complex space, the lack of constant overhead for graphical presentation is a plus, as is the simplicity of the base language. What I'm still looking to do is to write a simple outline -> GraphViz converter which sets up edges based on indent levels and parent, which would further simplify the input problem.
There's also treesheets. It's a nested table editor, but the tables can also be rendered as mind maps. My description doesn't really do it justice, but it's pretty cool.
The author's examples -- proofs and ASTs -- provide a hint at the reason.
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.)
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).
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.
LaTeX has styles for type setting proofs which look like the ASCII ones in the article.
Tools for generating parsers often have tree-based UI's.
You're right that most of the time we need non-trivial algorithms or visualizations for trees for it to be useful. If I ignored that it would be like wishing for a "general binary editor" because it would be so "powerful" and all data can be represented as binary.
I think, though, that there's enough common ground between the various domain-specific tree editors that some kind of useful intersection exists. Then the domain-specific tree editors would simply be plugins.
Perhaps the "killer app" is an extensible GUI framework with some sensible defaults already implemented (e.g. those mimicking some of the design dimensions explored by the software mentioned in other posts), combined with a scripting language and/or a suite of good libraries/apis for popular languages.
I think org-mode is a much better fit for what the author is looking for than mind-mapping programs, not least because org files can be literate programs.
Why did I have to scroll so far down for this! I was starting to think I was going to have to write "can't believe nobody has mentioned org-mode yet." myself.
Org-mode (and outliners in general) are tree editors. If they support links then they are graph editors.
Yep. I use org-mode every day. I think it's because most emacs users have gotten tired of typing "Yeah, emacs does that. Has done for a few decades now. And if it isn't precisely what you're looking for, here are a dozen ways you can customize the behaviour before you even get into hacking elisp." Most of us are in "whatever, if they haven't gotten it by now, I'm not going to try to make them" mode. I just wish there was a config setting in HN to filter out the "look! yet another new editor for programmers" spam on the front page.
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.
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: http://corelabs.coresecurity.com/index.php?module=Wiki&actio...
When I learned about D3.js this was exactly what I wanted to use it for. Unfortunately, I've mostly avoided web development, so my javascript isn't good enough to quickly code anything up. You're right, though, this could be a good excuse to learn it.
Graph layout algorithms have come to mind for a topic on my blog from time to time. It's a woefully underdeveloped field, and it could be good blog fodder...
My favorite casual text editor is this one [1]. So likewise I imagine a graph editing program that's very simple and one could use it anywhere. Say you click and that creates a new node and a text area pops up for you to type things in. Then you can create a new node, drag to form an edge, etc. The only thing is that I imagine I'd hate working around the force-guided graph layout algorithms the entire time, cause stuff would keep bouncing around. I'd want to be able to drag and drop nodes to move them away momentarily, zoom in and out and pan to focus my attention on some small part of the graph, and then toggle the layout algorithm to snap things back into place.
Everything would be stored locally in the DOM (or, say, in the url), so you could bookmark and share easily, and import/export to JSON or edge-list representations. And... yeah that's about it. I can't imagine wanting colors or styling, but if the design is simple enough you could have plugins for that (and plugins for layout algorithms, etc). I also can't imagine how one would do text navigation on nodes of large degree... Even if you did come up with a system, it would necessarily depend on the graphical layout decisions (which change dynamically) and that would require you to tie the graph data structure to its geometric interpretation, which smells like spaghetti design to me.
It's something to think about. If your ideas are along similar lines, I'd be happy to team up and start a github repo. I just can't commit to working on it all that often.
[1]: data:text/html, <textarea style="font-size: 1.5em; width: 100%; height: 100%; border: none; outline: none; font-family:monospace" autofocus /> (copy and paste this as a url)
EDIT: I suppose if you really wanted a keyboard-based system you could have a text representation of the graph (as a vertex list + edge list) and have the graph update in real time. When you make changes in one side the changes automatically update in the other side. Then you could use keyboard or mouse however you see fit.
I wonder if this good be a Getting things Done tool. You'd probably need multiple of those trees and a way to put simple, wiki-like multiline articles (maybe markdown syntax?). I'd use something like that!
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.
that isn't true. there are tradeoffs between using an adjacency matrix, and other representations. different operations will be more efficient on different representations.
and in the special case of extremely sparse graphs like trees, the adjacency matrix isn't going to win very often.
your copy of CLRS should discuss all of this. and for practical uses of non-adjacency matrix representations of trees, you can take a look at every functional programming language, ever.
You can represent trees with matrices. You can also represent trees with bits. What we want is a representation that is both easy to read and easy to write.
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].
I was just about to write that...
I barely know it but it seems it can be summed up as a hybrid of mind mapping [1] and literate programming [2], with a graph data model [3].
It's status somewhat resembles Org Mode: it has its own format (which hasn't caught on as interchange format) but has sufficient manipulation and export power to allow some people to spend their life inside it.
---
The second thing that spings to mind is YAML which is usually used for trees but the actual data model allows graphs.
Is there any structured YAML editor (a-la paredit)?
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'm definitely thinking of making a graph based text editor.
I think I could work off of code-highlighting files to figure out where to break code out into different nodes.
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).
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.
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.
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.
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."
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.
Others have mentioned GraphViz, which is a general purpose graph description utility.
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.
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.
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.
Frontier was one of my first experiences with programming and I still have a soft spot for it. Small nit: Frontier was the environment (object database, etc.), UserTalk was the scripting language Frontier used.
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)
I am sorry but Calibre and Bibdesk are completely different programs. I have used both programs and I am surprised you would say that calibre is an alternative to bibdesk. Calibre's focus is ebooks and bibdesk's focus is bibliographic information. The only possible overlap is that they both create a directory with electronic reading material. In order to get calibre to organize a directory like bibdesk (ie configured by author/journal/year) you have to jump through a million hoops and it requires duplicating your library. Have you ever used Bibdesk?
I grudgingly use calibre for epub/mobi conversion. Calibre's UI is ugly and it is not very usable: there are three separate pairs of arrows on the ebook preview screen! How would you decide which pair is for pgup/pgdn? And what would a user expect the use is for other two sets?
I would assume no one has mentioned Tinderbox because (a) it's $250, and (b) is Mac only. I'm just guessing that this has served to self-filter a lot of folks here (Linux/Windows/open-source-only folks have no idea of it).
Fascinating project, what library did you use for your HTML based graphs? I'd be interested in using it, I was thinking about building something similar the other day. Great work.
or JSON or S-EXPR; or structures in memory with pointers between nodes (multiple ways to do that, also very specific to the current programming language) and you can store that with some serialization mechanism; or records in SQL table with links as foreign keys (nasty); or object oriented databases (overkill)
It is hard to do them all, or to come up with one solution that pleases everybody, therefore everybody is doing his own tree. Maybe that's not the most general solution, but in reality you really need this one particular choice of tree representation to do your job.
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.
I've done talks about Xiki at RubyConf, Strange Loop, and QCon. Here's a quick 3 minute video - https://www.youtube.com/watch?v=bUR_eUVcABg. I'm doing a Kickstarter campaign soon, to bring Xiki support to vim, sublime, and possibly other text editors!
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.
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.
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.
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.
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.
> 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.
I agree with you on everything except this: code folding is very useful in creating a high level view of code to reason about. I would argue further for code bubbles, but they haven't really been done right yet; perhaps we will eventually see some interesting good solutions in LightTable.
Agreed. I frequently mention Code Browser (http://tibleiz.net/code-browser/) which has multi-level folding that works very well. When I work solo on a project, I tend to fold many levels deep and create what would otherwise be a "smell" but it doesn't seem to cause problems. Unfortunately, I can't use it when working with a team because I know of literally nobody else who uses the editor.
I've considered writing a plugin for LightTable or perhaps Sublime Text but I have no experience with either of their API's and I am not sure whether it would even be possible.
"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."
Definitely...Also, trees are pretty abstract data structures. You can imagine a min-heap as a tree but for practical purposes you can also think of it as an array where there are special rules for interacting with elements (adding, removing, finding the child of a node, etc). It could be a pain to try to generalize something so abstract and with so much room for complexity by making a tree editor...
It's the same reason why UI's for software development haven't taken off. When something is that abstract and complicated, it's almost harder interacting with an interface that tries to 'dumb it down'. Not to mention the lack of control such interfaces would introduce.
> Also, trees are pretty abstract data structures. You can imagine a min-heap as a tree but for practical purposes you can also think of it as an array where there are special rules for interacting with elements (adding, removing, finding the child of a node, etc).
This seems to be a bit of a red herring: you can think of an array as a contiguous region of bare bits in memory where there are special rules for interacting with elements—and similarly for any data structure—but that point of view doesn't seem to be the most useful (except possibly, in the array case, for programming in C).
I tend to see sexps as a general tree and emacs+paredit[1] as a general tree editor, and even though I completely agree about your point on 'if you need folding maybe your design is wrong hence no need for tree structures'. I really feel limited whenever I use a non sexp based language. It's like having you're own little private refactorer at your fingertips. And even for small code it's a noted pleasure.
[1] emacs or whatever program you use, as long as it give you tree walking keybindings.
Lots of interesting points, but I disagree with the logic that "we are not designed to handle more than one layer at a time" necessarily implies that a tree-editor is impossible/undesirable.
Yes, we are only built to think of an idea/code/story/essay at one "level" at a time. You are either thinking about the overall structure of the code, or a particular line. A particular scene, or the overall plot.
But that's precisely why a tree editor, one that separates the levels for you, is so useful. You can always "zoom in" to the details by going right, and "zoom out" to the big picture by going left.
Have a look at Gingko, for our approach to solving this problem: http://gingkoapp.com
I created GraphBin (http://graphbin.co) 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.
Maybe not a general purpose tree editor, but at least it's helped me out so far :)
Hit Selection Mode > Press and hold "s" for source node and click on the node you want > Press and hold "t" for target node and click on the node you want > Once the names of the nodes appear to the left under the header "+/- Edge", hit Add Edge.
You already have fairly general-purpose tree editing right under your nose - look at GUIs for your filesystem.
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.
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.
Looking at the screenshots reminded me of Leo. I only used it a little bit but liked it.
From their homepage:
> Leo is a PIM, IDE and outliner that accelerates the work flow of programmers, authors and web designers. Leo's unique features organize data in a revolutionary way:
> * Leo outlines are views on an underlying graph.
> * Outline nodes can reside in many places within a single outline.
> * Leo is fully scriptable in Python.
> * Leo scripts have full access to Leo's source code and all outline data.
> * Outline-oriented markup generates external files from outlines.
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.
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.
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.
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.
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.
A very nice and simple solution for visualization of small trees is to parse plain text with XSLT and transform it into SVG [2].
For are more programmable concept i would recommend to have a look at the combination of D3js [3] + JSON (or XML).
We have file tree viewers, and standard GUI components like Java's JTree.
I only skimmed, but the article didn't seem to address the questions raised ("why?"), but instead described the problem and proposed solutions.
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.
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.
Ashton Tate made a tree editor called [Framework](http://en.wikipedia.org/wiki/Ashton-Tate#Framework) 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).
Each frame held other frames, or could hold text, a spreadsheet or a database.
It wasn’t a DAG (directed acyclic graph) which was frustrating sometimes.
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.
The people who grokked it loved it.
I think there is still a [closed source](http://www.framework.com/) community supporting it, last time I looked.
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.
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'm writing one. Inspiration from http://www.treepad.com/
I use Treepad for notes heavily. Now I want to be able to manipulate the tree programmatically.
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.
The program is general purpose (different kind of node can be handled with plugged-in "drivers").
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:
Wow, it's not often that I see something that makes me sad I wasn't the one who implemented it, but damn this is one of those. Beautiful and elegant, really nice. Thanks for linking to it.
This takes me back to high school when a friend and I goofed around with spatial navigation through hierarchical structures. Of course that was in the era of the 486, and we had no idea what we were doing, trying to build something based on vector graphics with Pascal on DOS... so this was what we were dreaming of but couldn't make (nor properly articulate).
Code envy: yes indeed! :) Apart from the nice graphical touches like animating the branches and zooming and whatnot, the node-based navigation looks like a win for dealing with scale issues.
It's also nice that he abstracted the layout so thoroughly that he can not only create a variety of 2D and 3D views, but also map the underlying data structure onto actual game elements in the game's main display, as you can see in one or two of the other demo videos.
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".
Beyond this, yEd[2] is really quite cool (even if it does have a very dated UI).
Productivity problem because of degrees of freedom.
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.
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".
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.
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".
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.
reply