Live data from Hacker News

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

pcmonk.me

51–60 of 222 posts

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

#52
post #27

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…

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…

Based on Paredit keybindings, I don't think 'sibling', 'union' and 'splice' would be enough for convenient editing; you'd at least need a set of keys to move nodes (with their subtrees) around.

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

#55
post #50

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…

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

#56
This 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 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)

#57

https://github.com/gephi/gephi > Gephi is an award-winning open-source platform for visualizing and manipulating large graphs.

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.

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

#58
post #7

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

Not all graphs are expressed as code, or should be.

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.

Post reply on HN