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

31–40 of 222 posts

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

#31

Post by m1el »

throwanem wrote: post #10
m1el wrote: post #3

Emacs has ParEdit minor mode which is a general-purpose tree editor. https://www.emacswiki.org/emacs/ParEdit edit: paredit demos: Productive Emacs: Paredit https://www.youtube.com/watch?v=T1WBsI3gdDE Emacs Rocks! Episode 14: Paredit: https://www.youtube.com/watch?v=D6h5dFyyUX0

Maybe link to the Emacs Rocks demo in future - just a thought. I share it because I've known about paredit for years and just kind of gone ¯\_(ツ)_/¯ and not bothered - but seeing that demo has sold me on the idea in a super big way, to the extent where it's going to impair my productivity today, or would if we weren't in a post-crunch breather. By comparison, the Emacs Wiki article is a poor introduction, because int…

Thanks. Added links to paredit demos.

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

#34

Post by tim333 »

janci wrote: post #19

Somewhat related: I was overwhelmed by complexity of web CMS solutions. I needed something very very simple, that gets the task done (user-editable webpage content). I represent the web by a tree, every node has metadata (id, type, title) and data. Nodes can be persisted (ie. as json text files, or in database table) and browsed (parent to children and back). Admin UI is very simple: in the left pane there is the tre…

I'm not sure how you'd get that simple enough for users? For example if you do inspect element in Chrome it shows the page as a tree structure and it's not simple. Here's some of it for your post http://imgur.com/a/svB4J

I couldn't get the full 14 level tree to fit on my screen.

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

#35

Post by throwanem »

Filligree wrote: post #21
throwanem wrote: post #20

Earlier quoted context omitted.

I should take a look at that, in case there are features there that org-mode doesn't already have and are worth stealing. More seriously, that looks like at least a sizable subset of org-mode's capabilities, implemented in a way that doesn't require clearing the hurdle that getting comfortable with Emacs tends to be. How is it on the import/export/interop side?

Never mind Emacs, Emacs is easy. Org-mode itself seems like a tool where you have to read fifty pages of documentation to make good use of it. Maybe I'm exaggerating, but I've tried it a couple of times, and it never seems to be worth the complexity penalty vs. using a plain text file.

It depends what you mean by "good use", I suppose; I started out with just the very basic outliner and checklist features, and expanded from there. It didn't take much more than knowing those features existed, and what they looked like, to start using them. You do need to refer heavily to documentation when getting started with more complex features, but that seems like a fair tradeoff to me.

I'm also not sure what you mean by "complexity penalty vs. using a plain text file", since Org files are plain text files, with all the magic implemented in the UI layer - I regularly edit Org files on my phone with Editorial, and while the UI is obviously rudimentary by comparison, such editing is not actually difficult to do. Will you elaborate on what you mean here?

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

#37

Post by jessriedel »

al2o3cr wrote: 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…

This sounds like something that can only be true for equations below some size. If you're trying to manipulate a sufficiently large equation, it has to be automated, so directly editing text is bound to lose (however clunky the automated method may be). So maybe your experience is just that equations rarely get large enough to make it worth it to use a graphical editor?

For instance, doesn't the fact that people do pure algebra with Mathematica (forgetting about all the numerics, integrals, etc.) demonstrate that TeX loses for sufficiently large equations? Even if one only needs to use one or two functions with a very obvious tree interpretation (e.g., distributing multiplication over addition), Mathematica beats TeX for large enough equations.

What graphical equation editors have you used? This was what turned up when I searched google: http://equalx.sourceforge.net

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

#39

Post by m_mueller »

al2o3cr wrote: 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', 'union' and 'splice', right? That really wouldn't be more difficult than text operations IMO. I could see this for all sorts of purposes, starting with a standard configuration GUI for json / xml config files.

[1] because damnit these are still the only sane and consistent table hotkeys.

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

#40

Post by leni536 »

jessriedel wrote: post #37
al2o3cr wrote: 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…

This sounds like something that can only be true for equations below some size. If you're trying to manipulate a sufficiently large equation, it has to be automated, so directly editing text is bound to lose (however clunky the automated method may be). So maybe your experience is just that equations rarely get large enough to make it worth it to use a graphical editor? For instance, doesn't the fact that people do p…

I regularly edit large equations in LaTeX. I don't see how it's not manageable, just break your equations into multiple lines.

  \begin{equation}
    H_n(i) = 
      \begin{cases}
        \left(
          H_{n-1}(i)_2,
          H_{n-1}(i)_1
        \right) &
        0 \le i
> For instance, doesn't the fact that people do pure algebra with Mathematica (forgetting about all the numerics, integrals, etc.) demonstrate that TeX loses for sufficiently large equations?

I use Mathematica, and I just use the plaintext Mathematica syntax for large equations too. I also break these into multiple lines.

Post reply on HN