Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Don't We Have a General-Purpose Tree Editor? (2014)

pcmonk.me

Post reply on HN
Print view View original

191–200 of 222 posts

Re: Why Don't We Have a General-Purpose Tree Editor? (2014)

#191

Post by chriswarbo »

chriswarbo wrote: post #120

Surprised nobody's mentioned Boxer, or some other boxes-in-boxes representation http://web.media.mit.edu/~mres/papers/boxer.pdf 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" c…

After some Googling I've come across 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 and either https://en.wikipedia.org/wiki/Semigraphics or the new cairo support for drawing pretty borders?

Re: Why Don't We Have a General-Purpose Tree Editor? (2014)

#192

Post by CamperBob2 »

bsenftner wrote: post #161
melloclello wrote: post #55

Earlier quoted context omitted.

I've also been thinking about this for about as long (read this same article about 2-3 years ago), and came to pretty much the same conclusion. I actually think defining the grammar for turning text into a tree is likely to be the easy part, compared with building the editor itself. 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…

Back in '84 I was an undergrad at Boston University, doing an independent study with one of the business professors, Dr. Fedoritz, on a "next generation spreadsheet" that was to incorporate a cell-less freeform tree structure to represent Frames of Reference. Operating under the business school, we were working on advanced interfaces for financial professionals. The project was called a Frame Based Knowledge Represen…

Sounds like your professor invented HyperCard, more or less. Right idea, wrong time/place.

Re: Why Don't We Have a General-Purpose Tree Editor? (2014)

#193

Post by chriswarbo »

gcatlin wrote: post #148

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…

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

Re: Why Don't We Have a General-Purpose Tree Editor? (2014)

#194

Post by tunesmith »

YeGoblynQueenne wrote: post #176

>> 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…

Would that support an edge between b and e? That's what determines whether something like an outliner would be a good UI for it. If you need that support, then the UI becomes more difficult - you either have to "draw" the graph visually, or have a continually adapting approximation.

Re: Why Don't We Have a General-Purpose Tree Editor? (2014)

#195

Post by chriswarbo »

Something slightly more hardcode: 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.

Re: Why Don't We Have a General-Purpose Tree Editor? (2014)

#196

Post by philsnow »

TuringTest wrote: post #110
neonnoodle wrote: post #74

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 rhizom…

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/transformat…

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

Have you seen DDD (the Data Display Debugger) ? It's a graphical shell around gdb, and can help visualizing data structures.

Re: Why Don't We Have a General-Purpose Tree Editor? (2014)

#197

Post by TeMPOraL »

unhammer wrote: post #177
stcredzero wrote: post #149

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 pr…

def f = x = readline; g x def g x = print x; f

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.

Re: Why Don't We Have a General-Purpose Tree Editor? (2014)

#198

Post by chriswarbo »

YeGoblynQueenne wrote: post #176

>> 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…

Your representation is certainly valid, but I think those properties (light-weight, intuitive, etc.) apply to your example rather than your representation.

For example, imagine representing the HTML of this Hacker News page in your format; it would be completely unwieldy, and Hacker News is notoriously simple as far as HTML goes.

It's clear that this representation is massively space inefficient, since it repeats the vertex labels over and over. It's also massively time inefficient for common operations, like finding the incoming/outgoing edges of a node; these can be seen "at a glance" in some representations, like boxes + arrows, whilst your representation requires traversing the entire set of edges looking for matches. In fact, I can't figure out a sensible way to even write down the vertices in such an example! Even if we invented some arbitrary labelling scheme, e.g. labelling nodes based on their path from the root, or based on their position in a post-order traversal, such labelling schemes would be enough to define the tree on their own!

Unfortunately I think this is another case of trying to shoehorn sets into places where they don't belong for no particular reason, as if trees are somehow "less mathematical" than sets. It didn't work for Bertrand Russell, and it doesn't work here ;)

> if you want a graphical representation there's always tools like graphviz

Graphviz is notoriously messy when it comes to graphs of any nontrivial size, and the existing tooling makes interaction less than ideal (e.g. using home-grown scripts on top of image canvases and hotspots, rather than established interaction methods like a widget toolkit).

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

I don't see the connection myself. Proof assistants are incredibly picky about what they allow (that's kind of the point ;) ); on the other hand, a tree editor would be used for "fast and loose" cutting, pasting, duplicating, rotating, swapping, etc. of arbitrary sub-trees in arbitrary structures. How would tooling like, say, Coq, help with that?

Re: Why Don't We Have a General-Purpose Tree Editor? (2014)

#199

Post by ClayFerguson »

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.

Re: Why Don't We Have a General-Purpose Tree Editor? (2014)

#200

Post by vertex-four »

arxpoetica wrote: post #181
audunw wrote: post #107

Earlier quoted context omitted.

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.

JSON is one of the most dominant tree-data formats on the web because of the awesome balance it has between complexity and simplicity. JSON fits the bill nicely.

Actually... it's one of the most dominant tree-data formats on the web because you don't have to bundle a parser with your client and then figure out the idiosyncrasies between your serialisation model and your language's object model, the browser gives you one for free and JSON is your language's object model. It's a lot more fiddly to deal with in languages which don't have a K/V map as the primary object model.
Post reply on HN