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.
Why Don't We Have a General-Purpose Tree Editor? (2014)
121–130 of 222 posts
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#122I 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.
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#123For the programming use case there is also Leo. http://leoeditor.com/ Leo is of particular interest because it automatically syncs between the tree and code files: http://leoeditor.com/tutorial-programming.html The approach is documented here: http://leoeditor.com/appendices.html#the-mulder-ream-update-...
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.
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#124For the programming use case there is also Leo. http://leoeditor.com/ Leo is of particular interest because it automatically syncs between the tree and code files: http://leoeditor.com/tutorial-programming.html The approach is documented here: http://leoeditor.com/appendices.html#the-mulder-ream-update-...
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 adv…
[deleted]
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#125We have it. It's called JetBrains MPS: https://www.jetbrains.com/mps/
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#126Interestingly, 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.
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#127honestly, 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..
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#128Did 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.
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#129Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#130This has been here before: 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…
Try spacemacs [0].
Emacs with IMHO better keybindings, lots of integrated packages which can be switched on/off as functionally related "layers".
For vim users has of course evil package.