Why Don't We Have a General-Purpose Tree Editor? (2014) - <AUTHOR> http://pcmonk.me/2014/04/01/why-dont-we-have-a-general-purpose-tree-editor.html? <comment><USER3> Emacs has ParEdit minor mode which _is_ a general-purpose tree editor.

[https://www.emacswiki.org/emacs/ParEdit](https://www.emacswiki.org/emacs/ParEdit)

edit: paredit demos:

Productive Emacs: Paredit [https://www.youtube.com/watch?v=T1WBsI3gdDE](https://www.youtube.com/watch?v=T1WBsI3gdDE)

Emacs Rocks! Episode 14: Paredit: [https://www.youtube.com/watch?v=D6h5dFyyUX0](https://www.youtube.com/watch?v=D6h5dFyyUX0)

<comment><USER4> How good is it?

I've never used it and I'm genuinely curious.

<comment><USER5> 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.

<comment><USER6> Good exercise. Thank you!

Also, there are alternatives. What do you think about them?

<comment><USER5> Don't know of any (could you name them?), so I don't have any opinion.

</comment></comment></comment></comment></comment><comment><USER7> 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.

<comment><USER8> While we might have some common idea what is text, we definitely not have common semantics! The resulting situation isn't so much different from trees.

And what do you mean by "s-expressions just too simple"? Isn't simplicity something to strive for?

<comment><USER7> > And what do you mean by "s-expressions just too simple"? Isn't simplicity > something to strive for?

I should stress "a bit". Actually, looking closer at s-expressions right now (I was writing based on what I remembered), I'd like to flip that statement. S-expressions are just a bit more complex than what I have in mind. Or alternately: they're equivalent under some trivial transformation.

It depends on how you look at things - there are supposedly many different implementations of s-expressions, which support different fundamental data types. The basic idea is simpler. There are no fundamental data types, just nodes. For example a 'bit' is a node which can contain one of two child nodes ('one' or 'zero'). Any tree which represents data in memory on a computer can be expanded down to a collection of bits. Though in a text representation or tree editor the user will generally have collapsed the tree such that they don't see individual bits.

What I have in mind could look more complex than s-expression in a different context though: the text file representation of the trees may have more syntactic sugar than s-expressions in lisp.

The representation isn't significantly different, but the focus is. I'm focusing more on things related to type theory, schemas, how to represent patches/diffs, standardizing parsing/generation and other transforms, etc.

<comment><USER8> I have reread your text several times, and don't get it. What do you gain by having no fundamental datatypes, only bits? What syntactical sugar is not expressible by s-expression + transformation rules?

I am working on something like that too, and I'm completely fine with symbols (with their arbitrary definition by lisp and user) being the fundamental elements.

<comment><USER9> > What do you gain by having no fundamental datatypes, only bits?

I'd say what you gain is reusability, mostly. When you impose a datatype on data, it comes with a series of constraints and expectations, so you can only use the data in the ways prescribed by its type.

If the data doesn't have attached a type of is own, you can use it in different ways at different contexts - this can be valuable for data transformation processes, such as compilation or system interfaces. I suppose you could get the same effect by casting the data to a new type when you change it to a new context.

I've read a bunch about applying semiotics theory to programming, and changing the meaning of the symbols "on the go" is closer to the way we think (inferring meanings from the signs adequate to the current context) than the old mathematical approach of "every datum has one well-defined type, and only one".

</comment></comment></comment></comment></comment><comment><USER10> 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.)

<comment><USER11> def f = x = readline; g x

def g x = print x; f

<comment><USER5> Not 100% sure how to interpret this piece of code, but my naive interpretation gives this AST:

      (def f ()
        (let ((x (readline)))
          (g x)))

      (def g (x)
        (print x)
        (f))

Writing in Lisp can open one's eyes about the underlying structure of the code.

<comment><USER11> My point was that "Code editing is tree editing" sounds a bit like if you can understand the syntax tree, you understand what the code does – which isn't true here. Trees don't show the recursion[1], and a tree-view of code (with e.g. folding) might even give a false impression that what's inside one branch is somehow self-contained. Ie. Turing Machines are more expressive than CFG's :-) Not that tree-view's aren't helpful (indentation is important, and editing Lisp with paredit is a real joy), but there's much more to code-editing than tree-manipulation.

[1] Unless your "tree"-view is actually a lazy call-graph …

</comment></comment></comment></comment><comment><USER12> I think it's important to distinguish between "tree-structured data" and "tree-structured UI"; many of the suggestions here and in the article's comments mention s-expressions (or alternatives e.g. using indentation or similar); many others mention diagramming/mindmapping tools. I think the real issue is how disconnected such approaches are from each other: why can't I press a key and have my parenthesised expression be expanded into a tree, or press another button to collapse a sub-tree down into a parenthesised expression?

I imagine a decent tree editor would let me:

\- Navigate and edit the structure and its contents in a linear representation, like using paredit on an s-expression.

\- Navigate and edit the structure and its contents in a more "tree-like" representation, e.g. as boxes+arrows, or nested boxes.

\- Toggle between display modes on a per-term basis, e.g. using boxes+arrows for the top-level (say, function definitions in a Lisp file) and s-expressions for the contents.

\- Fold/unfold terms/trees (code folding, but for expressions rather than lines)

\- Allow plugins/preferences tailored for particular trees, e.g. syntax colouring for programming language parse trees.

As a more elaborate idea, we could allow plugins to extend the tree/graph structure with "virtual" nodes, e.g. linking names to their definitions, documentation, tests, etc. as if they were code-folded parts of the source code.

<comment><USER13> > Fold/unfold terms/trees (code folding, but for expressions rather than > lines)

Emacs can hide/show blocks in Lisp expressions (and others). Install HideShow ([https://www.emacswiki.org/emacs/HideShow](https://www.emacswiki.org/emacs/HideShow)). I personally never use it, generally the right solution is to refactor (but there might be good use cases too).

> As a more elaborate idea, we could allow plugins to extend the tree/graph > structure with "virtual" nodes, e.g. linking names to their definitions, > documentation, tests, etc. as if they were code-folded parts of the source > code.

Basically, when working from Emacs through Slime, the Common Lisp backend (called Swank) injects such metadata to the runtime objects (source file if a file exists, original code, documentation). You could define your very own properties if you want, like how a particular form should be displayed to the user. What already exists, for example, is a way to define custom indentation rules for macros, which are used on the Emacs side to indent your code as you wish.

Slime also decorates values in the buffer so that they act as "presentation" objects ([https://www.common- lisp.net/project/slime/doc/html/Presentat...](https://www.common- lisp.net/project/slime/doc/html/Presentations.html)).

<comment><USER12> > Emacs can hide/show blocks in Lisp expressions (and others). Install > HideShow > ([https://www.emacswiki.org/emacs/HideShow](https://www.emacswiki.org/emacs/HideShow)).

Yes, I've used it before and it's quite nice.

I've not used Slime, or done any Common Lisp programming for that matter.

I do love Emacs, and calling out to a sub/inferior-process for language- specific info is a good idea; it can just be frustrating to actually get the darn things to work though. After failing to get Geiser to work for Racket, or ghc-mod || intero || dante for Haskell, I've resigned myself to being happy with just syntax colouring :(

</comment></comment></comment><comment><USER14> Trees are graphs with out cycles but you always end up adding cycles. Code is no exception. There have been endless attempts to create coding systems based on graphs. These systems promise extraordinary modularity and reusability and an ease of programming which will allow anyone to construct complex software with a few clicks and drags. So far everyone of these systems that I have seen in the last 25 years has fallen short of its promises.

If you pay attention to these characteristics you will begin to notice the regularity with which such systems crop up and die. In my experience there's no use trying to talk enthusiasts out of this idea. I even attempted such a system myself many years ago. It's almost a rite of passage.

The reason tree editors (aka graph editors with out cycles, yet) don't work is similar to why we use relational DBs, instead of more the natural interpretation of data as graphs, boils down to, graph algorithms are slow and complex. In practice the added complexity outweighs the perceived benefits. The way people currently edit code, although not perfect, actually works really well. You have to weigh the costs of moving away from a simple system that works against the benefits and complexity of the new system.

<comment><USER15> How do you feel about tools like Reaktor, which I assure you works very well indeed?

<comment><USER14> Reaktor is a audio program. There is actually a long history of this type of app working well. PD is an early example. This is indeed a limited type of programming.

Above I was referring to attempts to apply this idea to general programming. I'm not saying such systems are impossible just that it's a bad idea to assume it will make the programmer's life easier.

<comment><USER15> That's not very responsive. Reaktor's primary purpose is to produce audio, but it also allows one to build sequencers, user interfaces, graphics (eg spectrograms, from DSP primitives by build your own FFT modules) and all sorts of other tools. Besides, why is audio somehow an inferior sort of data processing?

</comment></comment></comment></comment><comment><USER16> 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.

<comment><USER17> > If you need a gui, you are automatically in domain-specific territory.

The author specifically describes a platform in which domain specific concerns are facilitated by plugins, so I don't see why we are "automatically in domain-specific territory". One could easily envision classes of plugins for drawing nodes and edges (perhaps a canvas DSL), plugins for enforcing the domain's specific rules, etc.

<comment><USER16> I appreciate the reply, but I humbly suggest that nothing is solved by saying "just use plugins". You can't build a good plugin architecture in the first place without understanding the problem domain & workflow.

This is not a new idea, people have tried it before. If there was a decent solution it would already exist. People have tried to make general purpose graph editors & tree GUIs & layout engines, and there have been a bunch of people that thought they were being smart by architecting it to accept plugins. There's a reason you've never heard of any of them; nothing was general purpose enough to stick around, and applications that didn't try to be "general purpose" have vastly superior UI/UX.

I spent several years building a tree editor (the animation sequencing project I mentioned earlier). I've also used well known tree editors in node-based gui apps for decades. (Check out programs for film & game production like Nuke, Maya & Houdini -- they are tree editors.) Simply put, there are not enough commonalities between applications in different domains to make it worth building a shared "general purpose" editor. The workflows, problems, and schemas are too distinct. The tree isn't even close to the hard part anyway.

</comment></comment></comment><comment><USER18> We do: [http://strlen.com/treesheets/](http://strlen.com/treesheets/)

<comment><USER19> Seems like a enhanced personal wiki and away from PIM style and more added MindMap style. I would say this is not a tree editor.

<comment><USER20> It allows you to edit a tree structure. Unlike most tree editors, which lay out the tree in one dimension, this uses 2 dimensions. How is that not a tree editor other than it looking unfamiliar to you?

</comment></comment></comment><comment><USER21> We do, it's called "the file system". Folders and directories galore. If you dont like folder icons and rectangular windows, navigate with MC.

The problem is not trees, they are readily available in many formats. The problem is schemas. If there are no rules on the branches everything becomes "Old_stuff" or "important_work" or whatever people do to their document folders as the tide turns.

You need trees layered over trees to provide some structure and get that sweet workflow QC. Graph-homomorphisms between trees that is, or slice categories over whatever structure you need to maintain. Trees (or graphs) in semantic/syntactic relationships stacked as high as you can muster. Usually this is presented as a two-layered structure-tree+data-tree system in end user applications, with a fixed semantic tree depending on the domain in application. The trick is finding the balance between end-user configurability of layers n+1 and the required knowledge to design useful structures. People who edit layer 2 should probably be domain experts, and layers 3 and above are best left to programmers and computer scientists. If this was a solved problem, nobody would buy CRUD-software, and a good half of us would be looking for work.

</comment><comment><USER22> I think we don't have a general-purpose tree editor for two reasons:

1\. Nobody knows what it should look like.

2\. Nobody knows how it should work.

I fear this article has left me as much in the dark on these points as I was before I read it. Perhaps someone else here will find something in it I missed.

<comment><USER23> FWIW the editor in Chromium's and Firefox's developer tools are pretty good. I'd really like to see something like that as a standalone tool for both trees and XML and see how far it can be taken.

<comment><USER24> For XML you may want to take a closer look at XML Marker 1.1 (it's old, freeware and Windows but still better than many other tools) and maybe Eclipse.

<comment><USER25> I think that sums it up. We really can't top crufty old Windows freeware?

There is a _gaping_ hole in the market.

<comment><USER24> The last time I worked on complex XML I even used XML Marker with WINE... it works there. If you want the Mercedes of XML editors you should take a look at Oxygen XML editor (this is not free but runs on more platforms than Windows).

<comment><USER26> +1 for OxygenXML - it is very actively developed and has its own CSS engine that goes above and beyond what browsers can do. So you can style your tree with CSS.

</comment></comment></comment></comment></comment></comment><comment><USER27> For the programming use case there is also Leo.

[http://leoeditor.com/](http://leoeditor.com/)

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

The approach is documented here: [http://leoeditor.com/appendices.html#the- mulder-ream-update-...](http://leoeditor.com/appendices.html#the-mulder-ream- update-algorithm)

<comment><USER28> Leo is fairly cool. Been around forever, but not many people know about it.

I'm a heavy Emacs and Org mode user. But at this time I've given up on being proficient in Emacs-Lisp and how it ties to the whole Emacs ecosystem.

So I searched for a self-extensible editor in Python, and find Leo.

I haven't taken the time to learn it really well, but I did fiddle with some tree editing in Python with it, and it works as advertised. If I didn't have to work for a living, I'd spend most of my time porting over the cool aspects of Emacs to Leo.

Unfortunately, the documentation/web site is very opaque. Not so bad that it's useless, but bad enough that if anyone wants to learn it well they'll have to do a lot of Google searching (in the mailing list) or code browsing.

Also, to be frank, it's not a great editor compared to Vim/Emacs. But that should be easily fixable with scripting/code changes.

</comment></comment><comment><USER29> FWIW, comparing my experiences with several different "graphical equation editors" (fundamentally a flavor of tree-editor) versus editing LaTeX code directly, the tree editor loses every time. Yes, the tree editor is capable of providing an amazingly efficient interface for modifying parts of an existing expression - but when you start restructuring the whole expression things get messy fast. The plain code method is a bit rougher to read / enter in simple cases, but since it's just text in a text editor it doesn't have the same complexity escalation when doing unusual reorganizations.

<comment><USER30> This sounds like something that can only be true for equations below some size. If you're trying to manipulate a sufficiently large equation, it has to be automated, so directly editing text is bound to lose (however clunky the automated method may be). So maybe your experience is just that equations rarely get large enough to make it worth it to use a graphical editor?

For instance, doesn't the fact that people do pure algebra with Mathematica (forgetting about all the numerics, integrals, etc.) demonstrate that TeX loses for sufficiently large equations? Even if one only needs to use one or two functions with a very obvious tree interpretation (e.g., distributing multiplication over addition), Mathematica beats TeX for large enough equations.

What graphical equation editors have you used? This was what turned up when I searched google: [http://equalx.sourceforge.net](http://equalx.sourceforge.net)

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

      \begin{equation}
        H_n(i) =
          \begin{cases}
            \left(
              H_{n-1}(i)_2,
              H_{n-1}(i)_1
            \right) &
            0 \le i < 2^{2(n-1)}
            \\
            \left(
              H_{n-1}(i-2^{2(n-1)})_1,
              H_{n-1}(i-2^{2(n-1)})_2 + 2^{n-1}
            \right) &
            2^{2(n-1)} \le i < 2 \cdot 2^{2(n-1)}
            \\
            \left(
              H_{n-1}(i-2\cdot2^{2(n-1)})_1 + 2^{n-1},
              H_{n-1}(i-2\cdot2^{2(n-1)})_2 + 2^{n-1}
            \right) &
            2 \cdot 2^{2(n-1)} \le i < 3 \cdot 2^{2(n-1)}
            \\
            \left(
              - H_{n-1}(i-3\cdot2^{2(n-1)})_2 + 2^{n}-1,
              - H_{n-1}(i-3\cdot2^{2(n-1)})_1 + 2^{n-1}-1
            \right) &
            3 \cdot 2^{2(n-1)} \le i < 4 \cdot 2^{2(n-1)}
            \\
          \end{cases}
      \end{equation}

> For instance, doesn't the fact that people do pure algebra with Mathematica > (forgetting about all the numerics, integrals, etc.) demonstrate that TeX > loses for sufficiently large equations?

I use Mathematica, and I just use the plaintext Mathematica syntax for large equations too. I also break these into multiple lines.

<comment><USER30> > 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.

</comment></comment></comment></comment><comment><USER32> This reminded me of Leslie Lamport's (of LaTeX fame) paper "How to write a 21st century proof" [0], where he argues that we should explicitly structure proofs as trees.

[0]: [http://lamport.azurewebsites.net/pubs/proof.pdf](http://lamport.azurewebsites.net/pubs/proof.pdf)

</comment><comment><USER33> Interestingly, visual programming and tree-editing has actually gained a lot of traction with non-programmers. Tons of the big video and audio production suites (off the top of my head: Houdini, Max MSP, Grasshopper, Nuke, Blender's node editor) are DAG-based authoring tools, and are a joy to use.

As a person interested in programming language design, that makes me wonder if visual programming might be the sort of thing that we as programmers don't use because it is, in some sense, "beneath us". You can argue that the complexity of a standard Max patch is much lower than your production system, but many production systems are "render database to JSON", which seems far less complex than, say, a feature film, many of which are made almost entirely in Houdini.

</comment><comment><USER34> See to me the problem is the notion of tree structure itself. Forgive me because I don't know the correct mathematical way to talk about this: a tree is a particular type of network in which nodes can have only one direct parent and thus only share siblings with the descendants of that single parent. What we are really lacking is a good network editor, which would encompass not only trees but also more complex rhizomatic network structures.

I think Ted Nelson's ZigZag structure is the closest anyone has come as yet, but manipulating those is NOT user friendly (to say the least). Visualization of multidimensional networks is difficult on many levels, particularly UI. At a certain point you probably come up against hard cognitive limits of human thought.

<comment><USER9> There's a core abstraction lurking behind tools like ZigZag, the Leo editor, hashtags, and C pointers/linked structures.

The hyperlink as the base abstraction allowed us to store and navigate individual nodes in a hypertext, but it doesn't work well for collections - thus it provides limited support for programmatic access.

Conversely, pointers & references in programming languages allow for easy handling/transformation of large structures (either loops or recursive traversal), but there have never been a really good visual representation beyond a few nodes, and are difficult to navigate.

A good tool should be based on an abstraction that worked well for linking information at separate places in the data space, and for retrieving collections as a whole. I have my ideas for how that abstraction should work, and even may develop a product around it eventually. ;-)

<comment><USER35> Can I email you? I'm working on similar ideas. I can't find an email address. My email address is in my profile.

<comment><USER9> Sure! I've just emailed you from my personal mail account.

</comment></comment></comment></comment><comment><USER36> [https://github.com/gephi/gephi](https://github.com/gephi/gephi)

> Gephi is an award-winning open-source platform for visualizing and > manipulating large graphs.

<comment><USER37> I use Gephi quite frequently, it's interface leaves a bit to be desired but I've quite often quickly dumped some data into it and come up with some interesting relationships I wouldn't have thought of until it was visualised in Gephi.

<comment><USER36> It would be quite possible to develop a plugin that provides a user input oriented editing experience.

</comment></comment></comment><comment><USER38> This has been here before:

[https://news.ycombinator.com/item?id=7511979](https://news.ycombinator.com/item?id=7511979)

It's an unresolved problem as far as I know. Lots of partial solutions. I ran into this again recently because I use tree editors extensively (mostly leo) for my daily routine and was searching for a better (more structured) replacement but I haven't found anything yet that beats leo.

Emacs org mode is reportedly extremely powerful as well but I have yet to invest significant time into it (there is only so much time...).

<comment><USER39> I use org mode every day. It actually is a tree editor. You can fold and unfold entries, move whole subtrees into deeper/higher levels, etc. The tree editor however is just one of many org features.

</comment></comment><comment><USER40> A lot of tree editors aren't sufficient because he's asking about DAGs. Most tree-editing software only lets you have multiple children per parent, but you also need to allow multiple parents per child.

[http://flyinglogic.com/](http://flyinglogic.com/) is on the right track. JVM cross platform and commercial.

Curious how jetbrains MPS could improve on something like that.

</comment><comment><USER41> Isn't XML already a tree?

Joke aside, graphs are far from being trivial to represent as a data structure, and their use are so various that you can hardly edit a graph using text alone. Even a visual editor would require to be tailored to different work you do with graphs.

</comment><comment><USER42> Workflowy is pretty nice, it exports to plain text and xml.

[https://workflowy.com/](https://workflowy.com/)

<comment><USER43> I wish for something more sophisticated than workflowy, but I can't stop using it!

<comment><USER44> Try [https://dynalist.io](https://dynalist.io)

</comment></comment></comment><comment><USER45> And then there is Gingko[1], a beautiful, keyboard-shortcutted, markdown- enabled tree editor that exports to html, markdown, LaTeX, docx, impress.js, and json.

Gingko provide templates for Timelines, Screenplays, GTD and Academic papers, but I can imagine using it for complex formal proofs — I mostly use it for Microscope[2] and worldbuilding[3].

Right now it doesn't have any programmatic/computing capacity, but Gingko is eminently user friendly, so if Adriano[4] ever implemented a plugin system (or if someone wrote a Gingko-node-crunching chrome extension) I would imagine it to be a very enjoyable interface for editing trees.

1\. [https://gingkoapp.com/?ref=f32636d1](https://gingkoapp.com/?ref=f32636d1)

2\. [http://www.lamemage.com/microscope/](http://www.lamemage.com/microscope/)

3\. [https://www.reddit.com/r/worldbuilding](https://www.reddit.com/r/worldbuilding)

4\. [https://twitter.com/adrianoferrari](https://twitter.com/adrianoferrari)

Disclosure: I don't have any affiliation with Gingko, but that is my referral link. ;)

</comment><comment><USER46> [http://www.yworks.com/products/yed](http://www.yworks.com/products/yed) and GraphML ?

<comment><USER47> yed is the best tool for the job I've used so far, so I'm glad someone already mentioned it.

<comment><USER46> I have found it most handy for visualising data that I've dumped elsewhere in a simple format such as .tgf (generated dependency diagrams etc).

</comment></comment></comment><comment><USER48> 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.

<comment><USER49> >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.

Isn't that a pretty basic refactoring feature of most IDEs?

</comment></comment><comment><USER50> Architects and the like already work with a really great tree editor called Grasshopper. Easy to see cross sections through your tree as you are arranging components and relationships L->R or T->B, so there is potential to have very clear hierarchies depending on the style of the user.

Also, I've been impressed with a lot of the invention that has happened around Grasshopper's UX + UI. I've been really surprised to see the design community emerge with the best graph programming editor, as opposed to something much more developer focused.

It is of course not general purpose because you have to have Rhino to use it, but it can be used for general purpose programming since you can create custom components with .NET, ignoring most of the pre-built ones that are focused on parameterized geometry.

</comment><comment><USER51> I found myself thinking of something like Treeline when he describes what he wants. [http://treeline.bellz.org/](http://treeline.bellz.org/)

</comment><comment><USER52> Don't we have various LISP editors that are basically just that?

</comment><comment><USER53> This is a part of what we're working on at atomist - [https://www.atomist.com/](https://www.atomist.com/)

We're imagining the idea that your whole development flow is expressible in terms of trees and expressions that we can use to navigate those trees. Say for example a webhook pushes a commit event. We can navigate from that commit, into the chat channel associated with it. Find the repo that contains it. Associate it with the build and link the two together in chat or, most relevant to this article, navigate into the code itself and perform an action such as changing the code or opening a PR with a suggested edit and comment.

The interesting thing is that it's trees the whole way down. We can use the same expression to reach across all all kinds of events or to pick out individual tokens or structures inside the code.

There's lots of information on our blog: [https://the- composition.com/](https://the-composition.com/)

We've open sourced a lot of our core work at: [https://github.com/atomist](https://github.com/atomist) and are also interested in talking to teams about joining out alpha (see atomist.com)

It's a really interesting problem to be working on.

</comment><comment><USER54> honestly, let's go a step further and make it a general purpose graph editor!

practical purposes abound, sure, but I'd just like to see the intermediate notation that pops out if someone were to attempt to design one. I don't think it'd be like graphviz..

</comment><comment><USER12> Surprised nobody's mentioned Boxer, or some other boxes-in-boxes representation [http://web.media.mit.edu/~mres/papers/boxer.pdf](http://web.media.mit.edu/~mres/papers/boxer.pdf)

Blockly ( [https://developers.google.com/blockly](https://developers.google.com/blockly) ) is also similar, but I think it's a bit too specific:

\- Only one type of block is needed, to represent a generic "node" in the tree. Distinctions can be added by plugins, if desired for some particular language.

\- The idea of "interlocking" can be discarded, since a general tree editor should allow arbitrary edits to arbitrary trees (in the same way that a general text editor should allow any text to be inserted anywhere in a file/buffer). Plugins can add it back for particular languages.

\- Nesting should be the only relationship; it subsumes "sitting beside" (like Blockly assignments) or "wrapping around" (blockly loops).

\- No need to distinguish between editable/immutable values; everything is editable.

As a baby step towards the author's goal, how about an s-expression editor which displays boxes-in-boxes instead of parentheses? The editing commands could be exactly the same as e.g. Emacs+paredit, the only difference would be that indentation begins at the left edge of the current box, rather than at the left edge of the screen. For example, we would have to discard the indentation of an expression like:

        (foo (bar baz) (quux
           foobar))

Instead we would align "foobar" to be in the same box as "quux", e.g.

        +</comment><comment></comment><comment></comment><comment></comment><comment>-+
        |    +</comment><comment>-+ +</comment><comment>---+|
        |foo |bar baz| |quux     ||
        |    +</comment><comment>-+ |   foobar||
        |              +</comment><comment>---+|
        +</comment><comment></comment><comment></comment><comment></comment><comment>-+

Note that I don't recommend using ASCII to draw the boxes (except maybe as a proof-of-concept). Once we have such an editor, we could start to extend it with features like coloured boxes for syntax colouring, structure-checkers (e.g. "if" should have 3 children, etc.).

More radical extensions can then support pulling the boxes out into a more traditional tree structure.

<comment><USER12> After some Googling I've come across [http://foldr.org/~michaelw/emacs/](http://foldr.org/~michaelw/emacs/) which includes a hack for giving nested s-expressions different colours and hiding the parentheses. This sort of "tree view", combined with paredit's "tree editing", might go some way towards faking a tree editor.

Maybe this could be combined with [https://github.com/jacksonrayhamilton/context- coloring](https://github.com/jacksonrayhamilton/context-coloring) and either [https://en.wikipedia.org/wiki/Semigraphics](https://en.wikipedia.org/wiki/Semigraphics) or the new cairo support for drawing pretty borders?

</comment></comment><comment><USER55> I have wondered this exact same thing! I assumed tree editors did exist, and I was excited that all I needed to do was go find them. But Google did not come through for me.

Even a basic tree editor would be very powerful. Especially if you could run code from a repl that would change the tree (I know, that's no longer basic ... but it would let the graphical portion be basic, which might help it be bootstrapped into existence).

<comment><USER56> Outliners? ([https://en.wikipedia.org/wiki/Outliner](https://en.wikipedia.org/wiki/Outliner))

Heavy user of outline view in MS-word here, which is basically a tree editor for text documents.

</comment></comment><comment><USER57> >> We need a solid, simple program that can simply edit trees.

I might be misunderstanding this but a "tree" is a graph, so formally a tuple G = {V,E} where V a set of vertices {a,b,c,....} and E a set of tuples: {{a,b}, {b,c},...} so that each a,b,c,... are vertices in V.

So for instance, the graph:

        a
        |
       / \
      b   c
      |   |
      d   e

Would be written as {{V,E}: V = {a,b,c,d,e}, E = {{a,b},{a,c},{b,d},{c,e}}} possibly accompanied by a statement as to whether edges are directed or not.

That's a simple, intuitive, light-weight notation that is very easy to manipulate in a text editor, so that's probably why nobody has bothered to write a special-purpose program for it.

And if you want a graphical representation there's always tools like graphviz, so our graph can be written in dot-language as:

      digraph{
       a->b
       a->c
       b->d
       c->e
       }

Also, I don't understand why a tool to manipulate graphs, rather than just represent them, would be any different than a proof assistant or a theorem prover.

<comment><USER58> _> {{V,E}: V = {a,b,c,d,e}, E = {{a,b},{a,c},{b,d},{c,e}}} possibly accompanied by a statement as to whether edges are directed or not._

From a math notation point of view, this statement is not needed. If your edges are directed, denote your edges not as sets (which are always unordered in math), but as ordered pairs instead:

{{V,E}: V = {a,b,c,d,e}, E = {(a,b),(a,c),(b,d),(c,e)}}

<comment><USER57> Thanks. Or you can always use what I think is slightly informal notation, where a directed edge is notated as a -> b (I've seen that in textbooks, but I'm not sure where it's coming from).

<comment><USER58> Haven't seen this notation in text books so far, but I guess one of the following 3 things happened:

(1) The notation a->b was defined as a simple shorthand, i.e. a->b := (a,b).

(2) The notation a->b was defined to be the graph consisting of just a, b and the edge, i.e. a->b := ({a,b}, {(a,b)}) ... this may be followed by some algebraic rules about how to combine small graphs to build larger graphs.

(3) The notation a->b may be a somewhat misused notation for functions, meaning the only possible function from set {a} to set {b}, i.e. the function that maps a to b. If you define a function to be a relation (i.e. a set of pairs) where the first elements are unique, then this is acually equal to {(a,b)}, i.e. the set containing exactly this one pair.

Interpretation (3) might look somewhat contrieved, but it actually isn't that much of a stretch, given the connections between graph theory and function structures through category theory.

<comment><USER57> I believe it's (1) and I think it might originate in Judea Pearl's textbook on causality [1], particularly the section on the IC algorithm. I've also encountered it in a bunch of papers on graph reconstruction, by Wermuth, Lauritzen, Spirtes and Glymour (not all in one go, I don't think). For instance, see [2].

I guess it's convenient notation for a typical step in those algorithms, where two edges are oriented towards a common vertex- shown as A -> B <\- C or similar. That's a little more concise than {(A,B),(C,B)} but also more intuitive when the intention is to show how to (re)construct a graph from dependence relations, as those algorithms usually do.

___________________

[1] Causality; models, reasoning and inference:

[http://bayes.cs.ucla.edu/BOOK-2K/](http://bayes.cs.ucla.edu/BOOK-2K/)

[2] A Fast Algorithm for Discovering Sparse Causal Graphs; Peter Spirtes & Clark Glymour:

[http://repository.cmu.edu/cgi/viewcontent.cgi?article=1316&c...](http://repository.cmu.edu/cgi/viewcontent.cgi?article=1316&context=philosophy)

</comment></comment></comment></comment></comment><comment><USER59> Is it me or is this article reposted every four months? Does it show that there is a fundamental need that is still unmet?

</comment><comment><USER60> Think of this in terms of ordinal numbers.

When you have _text_ , you can interpret the string as a number and you can count the possible files: "0x01", "0x02", ... "0x0101", "0x0102", ... "0x010101", ... -- all of the possible files are enumerated by a _single_ increasing sequence. This corresponds to the ordinal "omega-0".

When you have a _table_ , you can interpret each _row_ as a number and now you have an arbitrary number of infinite increasing sequences, but you can imagine a transfinite "sequence of sequences" that counts the tables with 1 row, then the tables with 2 rows, and so forth. This is a single infinite increasing sequence of infinite increasing sequences, which corresponds to the ordinal "omega-0 squared".

But when you have a _tree_ , there's an infinite increasing sequence corresponding to... every single finite tree! In fact, there are _multiple_ increasing sequences corresponding to every finite tree, and infinite sequences associated to those sequences, and... anyway, tree-counting functions are very hard to define at all, but with a little bit of work in combinatorics you'll find something called a "Veblen function" which is defined so that the _parameter_ of the function is the number of _levels_ of recursion of infinitary functions applied to themselves, and then the fixpoint of the Veblen function itself is the Feferman-Schutte ordinal, which cannot even be _defined_ in first-order logic! One example of the horror that results from counting trees is Kruskal's theorem:

[http://en.wikipedia.org/wiki/Kruskal's_tree_theorem](http://en.wikipedia.org/wiki/Kruskal's_tree_theorem)

In other words, trees, which can encode arbitrary structure, are much more difficult to do math on than tables and flat files, which can only encode simple structures.

</comment><comment><USER61> There is the Dot language: [https://en.wikipedia.org/wiki/DOT_(graph_description_languag...](https://en.wikipedia.org/wiki/DOT_\(graph_description_language\)) The files can be viewed with Graphviz.

</comment><comment><USER62> Honestly, if I'm trying to organize some concepts into a tree, I'll go into Word, open a blank document, and switch to Outline mode.

Not the most complex solution but also super easy to use. Tab to indent, shift-tab to unindent. Select-drag-and-drop... etc.

</comment><comment><USER63> Take a look at Parinfer[0]. It's for Lisp editing, but S-expressions are as general as it gets.

Also you can use Ranger[1] or Finder or NERDTree with Vim/Nvim to utilize your file system as a tree structure and afterwards "extract" it with tree[2]

[0] [https://shaunlebron.github.io/parinfer/#introduction](https://shaunlebron.github.io/parinfer/#introduction)

[1] [http://ranger.nongnu.org/](http://ranger.nongnu.org/)

[2] [http://mama.indstate.edu/users/ice/tree/](http://mama.indstate.edu/users/ice/tree/)

</comment><comment><USER64> I don't want a general purpose tree editor. I want a general purpose text editor that understands the semantics of the text I'm editing. One that understands all the various not-necessarily-sexp-based code I'm editing _is_ a tree and supports (ParEdit style) operations on that tree. Especially with languages in the Algol/C family. I think this can be accomplished (eventually) via language servers and editors that speak the Language Server Protocol (LSP) [0].

But I don't need a UI oriented around visually displaying tree-like things. Expanding / collapsing nodes is very meh. Moving / splitting / joining nodes is _much_ more interesting and useful.

As a simple concrete example: changing the order of the parameters (and their type) in a function definition. Wouldn't it be great to 'swap-with-prev-node' or 'swap-with-next-node' rather than copy/paste and dealing with commas? The same operations could swap the order of two fields in a struct or two functions or two classes or _any_ pair of adjacent nodes in a tree.

Or how about moving an 'if' block inside the 'for' block that follows it? Just execute the 'move-node-inside-next-node' (or whatever) command.

This only requires editors that (indirectly) understand the semantics of the text you're editing. Thus far the biggest barrier is all wheel re-invention needed for the cartesian product of all editors and all languages. But that's the wrong approach. We need each language to provide a tool that each editor can use via a common protocol.

This is precisely the point of the LSP. The functionality only needs to be written once per language and per editor. This is totally tractable. I don't know if LSP currently supports the specific tree-manipulation functionality I mentioned, but I'm confident it could.

Does anyone knowledgeable about LSP know if this is already possible, feasible, and/or generally desirable? Are there deal breakers that make this hard / not worthwhile?

[0] [http://langserver.org/](http://langserver.org/)

<comment><USER12> Keep in mind that it's pretty trivial (if laborious) to make parsers/pretty- printers between your language of choice and s-expressions, which would allow a generic tree editor to work on your language.

Note that you _don 't_ need a fleshed-out, implementation-friendly _abstract_ syntax tree (e.g. "(definition (name foo) (type (function int int)) (arguments ((name x) (type int))) (body ...))"); you just need a parse tree of the tokens (e.g. (def foo ((int x)) ...)).

I agree that the existing silos of VisualStudio, Eclipse, Netbeans, jEdit, Emacs, Vi, etc. is a bad thing, and initiatives like LSP are is a step in the right direction.

Another nice approach that I came across recently is [https://github.com/CarlOlson/structured- editing](https://github.com/CarlOlson/structured-editing) . This also uses a separate process to get information about code, but uses "spans" (start position, end position, label, extra info) which seem to be in between strings and syntax trees. For example a span might encompass a class definition; another span covers a method inside that class; another covers a statement in that method; another covers a function call in that statement; another covers the function name in that call, and it's extra info includes the location where that function is defined, its type, etc.

</comment></comment><comment><USER65> Somewhat related: I was overwhelmed by complexity of web CMS solutions. I needed something very very simple, that gets the task done (user-editable webpage content).

I represent the web by a tree, every node has metadata (id, type, title) and data. Nodes can be persisted (ie. as json text files, or in database table) and browsed (parent to children and back). Admin UI is very simple: in the left pane there is the tree browser, works like filesystem browser - you can open "folders" (nodes with subnodes) and "files" (leaf nodes). Each node shows specific editor for it's type, that usually consist of few form fields.

<comment><USER66> If I understand you correctly, ProcessWire has such an admin UI out of the box: [https://processwire.com/](https://processwire.com/)

You can build your own admin UI, if you want as it's all done with the same API you use to build your sites.

</comment></comment><comment><USER67> Author of code2flow here ([https://code2flow.com](https://code2flow.com)) - <USER2> think you could use my tool to easily create many types of trees. It's not generic, as in, it is focused on charting programs/algorithms and workflows but I've seen people (ab)use it for many different use cases, like so: [https://code2flow.com/fRRlCK](https://code2flow.com/fRRlCK)

</comment><comment><USER68> Little Outliner 2 is pretty good. [http://littleoutliner.com/](http://littleoutliner.com/) Made by Dave @ scripting.com

<comment><USER37> Went to try it out but it requires signing into your twitter account and they get access to:

\- Update your profile.

\- Post Tweets for you.

That's not cool.

<comment><USER69> OWL is a nifty fork of Dave Winer's work that stores all data locally and doesn't require a Twitter account.

[https://github.com/interstar/OWL](https://github.com/interstar/OWL)

<comment><USER68> That looks interesting. It also has a web.py server that can be used to store data on a server somewhere.

Good stuff.

</comment></comment></comment></comment><comment><USER70> We have it. It's called JetBrains MPS: [https://www.jetbrains.com/mps/](https://www.jetbrains.com/mps/)

</comment><comment><USER71> Because we don't have a general-purpose tree file format.

<comment><USER72> XML?

<comment><USER73> [http://rupy.se/logic.jar](http://rupy.se/logic.jar)

More than tree structured XML, this also provides node graph XML visual editing.

</comment></comment></comment><comment><USER74> This certainly is good question. But, the fact that we don't have one yet maybe tells us that we haven't defined what it should be and what kind of problem it should solve.

I mean, I like the idea a lot! Used MindNode, but I found it very bound to specific type of problems. It is visualization tool. And Emacs is just too much. I use it from time to time, but I would like nice native general purpose text editor with Tree capability and Markdown support.

</comment><comment><USER75> This may sound cruel, but you can use OmniOutliner as a tree editor and transform the XML to your target with your favorite xml transformation method.

</comment><comment><USER76> I have a startup called Wizely, which is a social wisdom network. The iOS (phone) app (in development) will have a tree editor. I'm also developing a tablet version that would be bigger and more "touch-friendly". A full browser/desktop version isn't in the works, but if things roll out according to plan, it would be an important addition to our process.

</comment><comment><USER12> Something slightly more hardcode: [http://hazelgrove.org](http://hazelgrove.org) \- structured editing via a formal calculus of actions which provably maintains correctness.

Whilst a cool idea, and a nice foundation for actions, it certainly suffers from being clunky UI-wise, so doesn't solve the author's problem directly.

</comment><comment><USER77> The author's use of "sufficient cause" brought to mind Sciral's Flying logic[0] which does some basic logic and sufficient cause in terms of Goldratt's Theory of Constraints. It's also useful for a number of other logical structures, like trees.

[0] [http://flyinglogic.com](http://flyinglogic.com)

</comment><comment><USER78> A tree is a pair of a value and a list of trees.

The "list of trees" part is what's constant about trees; the value is what makes it hard. What's a value? A name? A string? A text? Either a text, or a name and a map of strings to strings (simplified HTML)? A General Purpose Tree Editor would have to handle all those cases, and a whole lot more.

</comment><comment><USER79> What comes to my mind is the Eclipse Modeling Framework. It's not exactly light-weight, but it always worked pretty well for my use cases. Throw a model at it (XML schema, annotated Java, ...) and it generates a Java implementation including a tree-based editor; certainly good enough for prototyping purposes.

<comment><USER80> I'm curious about your use cases, as I do not seem to find much information about model-driven development out there. Can you elaborate a little bit more about what you do with EMF?

I'm asking this on the perspective of someone who is about to teach model- driven software engineering for a semester but cannot find much pratical use for it..

</comment></comment><comment><USER81> imagine you had about ten excel tables linked in a graph, any interesting visualization or analysis involves querying it like a database, and many databases are very rigid in terms what they can store, not flexible like excel. Semantic web stores (triple stores) are mostly schemaless and solve the rigidity but they had their own problems [1], datomic's 5-store model maybe fixes them? So maybe we will see an excel-for-graphs based on datomic someday soon. I'm working on this problem so if anyone has any interest in discussing this you should email me! It's a really interesting problem because excel-for- graphs would be an amazing starting point for building CRUD apps.

[1] can anyone help me with clarity here as to why triple stores failed? Is it because no :db/retract and no time axis so cache consistency problems? or a deeper reason?

</comment><comment><USER82> I've brought up this issue before in the context of GraphQL's declarative data: [https://github.com/facebook/graphql/issues/237#issuecomment-...](https://github.com/facebook/graphql/issues/237#issuecomment-270195701)

</comment><comment><USER83> If you can do queries AND have a GUI option that seems logical to me.

Looking back at my history this topic hits me right in the feels...

[http://birdhouse.org/beos/byte/25-formula_queries/](http://birdhouse.org/beos/byte/25-formula_queries/)

</comment><comment><USER84> Trees are not all alike and I think this stops most such plans. Some trees have types and tags, quoting of other trees, container patterns that are representable as a tree but unpleasant to edit.

And we get stuck on that and say "Let's have a syntax." And then we're back to text again.

</comment><comment><USER85> Did anybody get the source code to run? I've been trying to test it out for a long time but never really gotten anywhere. Is there anybody that is good at functional programming that could help me out?

It's surely funny if there can be so many comments and nobody even ran the program.

</comment><comment><USER86> [http://jsoneditoronline.org/](http://jsoneditoronline.org/)

It's only for JSON but you can write a small script to convert it to whatever format you want.

</comment><comment><USER87> I'd even be happy to have just a simple general-purpose text-ui tree viewer. There's tree(1) and ncdu(2) but they doesn't really work for anything except directory trees.

</comment><comment><USER88> I think this problem is closely related to the perennial "optimal to-do list" problem. A to-do list is a tree. If you have a good tree editor, you have a good to-do list app.

</comment><comment><USER89> Pretty much any code editor with a jump to source, is a user friendly graph editor. And with refactoring tools, a good debugger and compiler I can't see what is missing

<comment><USER22> Not all graphs are expressed as code, or should be.

<comment><USER5> Also, code in most languages is pretty far from being a tree on the surface.

Not to mention that "jump to source", et al. depend on particular _semantics_ of the code. So by itself, those features don't make a general-purpose tree editor.

</comment></comment></comment><comment><USER90> I must admit i have no clue what the author is actually asking for.

If he is asking for away to organize various bits of text etc, is that not basically a directory tree stuffed with files?

</comment><comment><USER91> Isn't this just what's known as an Outliner (e.g. OmniOutliner, but various other programs exist)?

</comment><comment><USER92> orgzly (open outliner saves in org mode for Android)

[https://play.google.com/store/apps/details?id=com.orgzly&hl=...](https://play.google.com/store/apps/details?id=com.orgzly&hl=en)

</comment><comment><USER93> 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 <b>bold</b> more text" or "text <span class='arbitrary_class'>span</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".

</comment><comment><USER94> seems like the next trello can be trello with graphs, diagrams and trees

</comment><comment><USER95> Thanks to this post I found out about TreeSheets. Looks interesting.

</comment><comment><USER96> Check out Freemind. It's been collecting dust on the shelves.

</comment><comment><USER97> Joe Celko's Trees and Hierarchies in SQL for Smarties (book) is a good start for better understanding/defining trees. [http://a.co/9eVzvji](http://a.co/9eVzvji)

<comment><USER98> There's a very useful chapter in Karwin's SQL Antipatterns on this topic too.

</comment></comment><comment><USER99> Lisp Machines had general tree editing facilities.

</comment><comment><USER100> Isn't that called Outliner?

</comment><comment><USER96> Check out Freemind

</comment><comment><USER101> Freeplane?

</comment><comment><USER102> Check gingko, which is more focussed on docs, but is a tree editor at its core.

[https://gingkoapp.com/](https://gingkoapp.com/)

Used it at university for notes, and is great for quick revisions before the exams too!

<comment><USER19> Looks great but it only does text. The link speaks of beyond ASCII. For this the old school PIM were better at storage of thoughts.

<comment><USER45> "old school PIM"? Wikipedia and I find this ambiguous [1].

1\. [https://en.wikipedia.org/wiki/PIM](https://en.wikipedia.org/wiki/PIM)

</comment></comment></comment><comment><USER103> To me it's shocking that there's nothing for editing XML that equates to an editable tree GUI interface where nodes and properties can be rendered onto something resembling a document but yet browsable (by expanding and collapsing node) with the same paradigm of a file-system browser gui. I'm working on this myself actually, in meta64.com (see it on github, because the site is not always live, and is experimental). I am using JCR as the back end data storage but seriously considering adding a feature so support direct XML editing. XML and also REST are highly structural, and yet everyone seems to just use syntax-highlighting text editors to edit them rather than something more akin to a tree-based browser, that would render something more friendly looking (with expand/collapse capability). Think of it like this, you have seen RSS XML before right? You have also seen web sites that RENDER the RSS feed into a document-looking thing. That's what i'm getting at. Going from editing this stuff as a text file, to something much more advanced, like a tree-browser. Maybe there are some things i'm not aware of, like perhaps even an Atom Editor plugin or whatever, but I don't think there's anything in wide use or i'd know about it, having been a web developer for 25yrs now.

</comment><comment><USER104> Blasphemy: All xml editors are General Purpose Tree Editors</comment>


Coinstar is kicking Netflix's butt - <AUTHOR> http://buzz.money.cnn.com/2012/06/15/coinstar-is-kicking-netflixs-butt/

<comment><USER2> In economics terms, this article proposes the idea that Coinstar's Redbox dvd vending machines are an inferior good when compared to Netflix.

<https://en.wikipedia.org/wiki/Inferior_good></comment>


Wahoo Fitness Desk - <AUTHOR> http://uk.wahoofitness.com/wahoo-fitness-standing-desk.html <comment><AUTHOR> I've been looking at standing desks and the requirements I want from them for some time. This is a bit of a left-field choice but I actually think it serves as a solid standing desk that can be used for cycle training.</comment>


Non-line-of-sight imaging using phasor-field virtual wave optics - <AUTHOR> https://www.nature.com/articles/s41586-019-1461-3 <comment><USER2> [https://arxiv.org/pdf/1810.07535.pdf](https://arxiv.org/pdf/1810.07535.pdf) \- actual paper

[https://xiaochunliu.github.io/](https://xiaochunliu.github.io/) \- author's GitHub page.

<comment><AUTHOR> thanks: [https://biostat.wisc.edu/~compoptics/Analysis%20of%20Feature...](https://biostat.wisc.edu/~compoptics/Analysis%20of%20Feature%20Visibility%20in%20Non- Line-of-Sight%20Measurements/Analysis%20of%20Feature%20Visibility%20in%20Non- Line-of-Sight%20Measurements_seb.html)

</comment></comment><comment><USER3> [https://arxiv.org/abs/1810.07535](https://arxiv.org/abs/1810.07535)

[https://sci-hub.tw/https://www.nature.com/articles/s41586-01...](https://sci- hub.tw/https://www.nature.com/articles/s41586-019-1461-3)

</comment><comment><USER4> It's weird to see a computational photography paper in Nature. It doesn't really seem like the right venue.

</comment><comment><USER5> This feels like the future.

</comment><comment><USER6> in simple terms, seeing around corners.

<comment><USER2> More like "anything that reflects some light is a mirror". It's now possible to undo diffusion by number-crunching. Not very well, though. See the pictures in the paper.

<comment><USER7> May be good enough as long as some features are distinguishable (say a person holding a gun). Thermal imaging isn't exactly the clearest, but it's very useful.</comment></comment></comment>