Earlier quoted context omitted.
>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. Ummm json??
I was wrong about S-expressions. S-expressions are roughly the right complexity, or even a bit too complex, depending on how you look at it. JSON is way too complex. JSONS assumes that you have an object/record structure (labels and values), and gives you both objects and arrays with which to build tree structures.
Why Don't We Have a General-Purpose Tree Editor? (2014)
181–190 of 222 posts
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#182>> 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 b…
> {{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)}}
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#183Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#184Trees 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 falle…
Just because a tool can't solve all problems in their generality doesn't make it automatically worthless, there are situations where less is truly more.
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#185Workflowy is pretty nice, it exports to plain text and xml. https://workflowy.com/
I also like mermaid (https://github.com/knsv/mermaid), so I created a small rails app (https://github.com/juliend2/metaglue) that uses mermaid as the graph language, and it generates an SVG graph in realtime. I really like it and use it as a kind of brain dump for various subjects. The idea behind it is to collect any kind of data (bits of knowledge) and mash them all together inside a common graph.
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#186Earlier quoted context omitted.
Don't forget org mode or mind mapping software. Both are quite able with hierarchical data.
Can you (or anyone) name some good mind mapping software (other than org mode)?
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#187The 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 pr…
def f = x = readline; g x def g x = print x; f
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#188Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#189Workflowy is pretty nice, it exports to plain text and xml. https://workflowy.com/
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#190Workflowy is pretty nice, it exports to plain text and xml. https://workflowy.com/