We do: http://strlen.com/treesheets/
Why Don't We Have a General-Purpose Tree Editor? (2014)
51–60 of 222 posts
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#52FWIW, 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…
But is this due to text being the most efficient way of editing or are our tools simply inadequate? Let's imagine a world that has standardized on certain UIs - just like TextMate/sublime style hotkeys are common in graphical editors, let's say we had iWorks[1] style table editing hotkeys everywhere and a TBD standard for tree operations that you could learn once and then apply everywhere. Basically you need 'sibling…
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#53Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#54We do: http://strlen.com/treesheets/
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#55I'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…
That said, during my research I ran across an ancient Usenet thread from 1989[1]. In it, the OP asks:
> Should the language designers be making work for the language-oriented editor designers or should the language-oriented editor designers be making work for the language designers?
(The thread rapidly devolves into an all out flame war about whether or not C can be considered to be context-free)
Lisp feels like a language designed specifically to make a language-oriented editor designer happy, but most other popular languages fail the context-free test one way or another, thus making them difficult to define good grammars for. The problem seems to be that historically the language designers have far outnumbered the language-oriented editor designers.
[1] https://groups.google.com/d/msg/comp.lang.misc/MCZmQv56--Q/O...
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#56https://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...).
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#57https://github.com/gephi/gephi > Gephi is an award-winning open-source platform for visualizing and manipulating large graphs.
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#58Pretty 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
Not all graphs are expressed as code, or should be.
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.
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#59Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#60http://www.yworks.com/products/yed and GraphML ?