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 introduction is not its purpose; it's there to collect resources for people who already use paredit, and a good introduction answers the question of why someonr would want to start.
That said, thanks so much for posting about it here! I'm really looking forward to learning it today.
It depends on your requirements. ParEdit limits you to only perform AST transformations, which could be very good if you edit s-expressions or explicitly tree-like structures.
If I was working on lisp-like languages, I would definitely use it. But ParEdit didn't stick to me, even after a few attempts. I didn't like the key bindings, and I think that the interface is too complex for me.
It's definitely written with the intent of using it to edit Lisp code, and for that it is great. It is now hard for me to imagine writing Lisp by editing S-expressions directly.
Pretty good, it almost make you feel you're working on trees and not text. Takes a few moments to get used to. I recommend what I did: take a bunch of Lisp code, strip it out of parenthesis (M-x replace-string, replace ( and ) with empty strings), and then use Paredit commands to restore the original tree structure. I spent less than an hour simply doing this exercise again and again, and it was enough to become a proficient user.
It is amazing for working with Lisps. I use it for Clojure and it is great -- highly recommend to anyone using a Lisp to learn it. Though you'll miss having it in other languages.
Not sure what it is like for other tree structures.
Mind maps are really just nested lists right? https://workflowy.com/ is one of the best nested list (tree) editors I've found for mind-mapping and note-taking.
I think we don't have a general-purpose tree editor for two reasons:
1. Nobody knows what it should look like.
2. Nobody knows how it should work.
I fear this article has left me as much in the dark on these points as I was before I read it. Perhaps someone else here will find something in it I missed.
FWIW the editor in Chromium's and Firefox's developer tools are pretty good. I'd really like to see something like that as a standalone tool for both trees and XML and see how far it can be taken.
The inspector? I've seen and worked with similar tools for XML, too, though not recently. They're very good for small, constrained hand-editing, but I find them to scale extremely poorly.
For XML you may want to take a closer look at XML Marker 1.1 (it's old, freeware and Windows but still better than many other tools) and maybe Eclipse.
The last time I worked on complex XML I even used XML Marker with WINE... it works there. If you want the Mercedes of XML editors you should take a look at Oxygen XML editor (this is not free but runs on more platforms than Windows).
+1 for OxygenXML - it is very actively developed and has its own CSS engine that goes above and beyond what browsers can do.
So you can style your tree with CSS.
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
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.
This reminded me of Leslie Lamport's (of LaTeX fame) paper "How to write a 21st century proof" [0], where he argues that we should explicitly structure proofs as trees.
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?
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?
As somebody who only makes a pretty basic use of org-mode I disagree.
Without having to read anything you just have to remember to use * to mark sections and * * for subsections and so on. Then you use tab to expand/collapse the sections. That's rather intuitive, not more complicated than a plain text file and already you have better highlighting and additional functionality.
Then sometimes I wonder "hey, I'd like to have a link to this URL in this file" or "I'd like to export this to HTML or PDF so that I can send it to my friend who doesn't use org-mode without losing the formatting". And then you look in the manual and you (generally) find what you're looking for.
Sure if you want to be an org-mode wizard you'll have to learn quite a bit but I really don't see "the complexity penalty vs. using a plain text file". The complexity is only here if you want it.
Edit: also the array auto-formatting is a godsend. Doing it by hand in text files is tedious.
It allows you to edit a tree structure. Unlike most tree editors, which lay out the tree in one dimension, this uses 2 dimensions. How is that not a tree editor other than it looking unfamiliar to you?
I just tried this on macOS. I really like the concept but: It does not conform to macOS UI standards (I could live with that), and it is very slow (I cannot live with that).
+1 for gingko -- it's especially great when starting a big document from scratch as it allows you to move and restructure entire documents, something that would be a lot of trouble with copy paste.
Gingko is phenomenal, heavy use of it will alter how you think and work, Sapir-Whorf style. Developer seems like a good guy who cares intensely. Happy to pay for this tool.
Joke aside, graphs are far from being trivial to represent as a data structure, and their use are so various that you can hardly edit a graph using text alone. Even a visual editor would require to be tailored to different work you do with graphs.
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 tree browser, works like filesystem browser - you can open "folders" (nodes with subnodes) and "files" (leaf nodes). Each node shows specific editor for it's type, that usually consist of few form fields.
I had to work with Pimcore CMS recently (https://www.pimcore.org/en) and was pleasantly surprised. It works like you describe, the data is organised very developer friendly (classes and collections of data a tree structure for organisation). I am not sure how regular people would get along with this but knowing only bloated, slow and clumsy wordpress in that space it was surprisingly efficient.
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.
Ca. 15 years ago, I used WebSiteBaker [0]. The website survives happily without any maintenance from my side. Only non-technical users changing content. There are a few minor things to do (e.g. CSS for mobile users), but I have no access anymore. I have no idea, how it has changed, but I would definitely try it again today.
This certainly is good question. But, the fact that we don't have one yet maybe tells us that we haven't defined what it should be and what kind of problem it should solve.
I mean, I like the idea a lot! Used MindNode, but I found it very bound to specific type of problems. It is visualization tool. And Emacs is just too much. I use it from time to time, but I would like nice native general purpose text editor with Tree capability and Markdown support.
What comes to my mind is the Eclipse Modeling Framework. It's not exactly light-weight, but it always worked pretty well for my use cases. Throw a model at it (XML schema, annotated Java, ...) and it generates a Java implementation including a tree-based editor; certainly good enough for prototyping purposes.
I'm curious about your use cases, as I do not seem to find much information about model-driven development out there. Can you elaborate a little bit more about what you do with EMF?
I'm asking this on the perspective of someone who is about to teach model-driven software engineering for a semester but cannot find much pratical use for it..
I'm not being facetious here ... but aren't XML, Json and Yaml popular tree-structured formats?
Like OP mentions Excel for instance, for editing tabular data, which isn't quite a standard file format, and in any case supports many different formats for tabular data.
I can't help but wonder if OP is focusing on "format" rather than the structure of the data itself. There's plenty of editors for these well known formats. Perhaps he just needs to restructure his problem to use one of these?
In XML for instance, it's fairly straightforward to implement a "plugin" such as he describes, using python or ruby and a DOM parser, which could amongst other things provide the different renderings described.
I remember using XML Spy a long time back which seemed to do this quite well, as an ever expanding grid of cells, click into a cell, and it would expand showing its constituent cells. There were different tree representations available as well.
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 a bit rougher to read / enter in simple cases, but since it's just text in a text editor it doesn't have the same complexity escalation when doing unusual reorganizations.
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
> 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.
> regularly edit large equations in LaTeX. I don't see how it's not manageable, just break your equations into multiple lines.
I understand how to indent TeX, but when you have a hundred algebraic terms it's very unwieldly, and Mathematica becomes clearly superior (for me) just to visualize it.
Anyways, it sounds like you're just saying you haven't found the graphical visualization for equation trees to be useful, so you stick with the linear representation, but the manipulations of those trees (by mathematica, or some other dedicated editor) is still useful.
In this case I would add that we would probably still need some sort of visualization aid for sufficiently large equations, and that the tools are just not good right now. After all, much/most code is written in normal (linear) text editors, but some people still do find it useful to "collapse" sections of code, corresponding to branches of the tree structure induced by indentation. Many people don't bother with this right now because it can cause headaches that simple scrolling does not, but better tools may change this.
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.
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.
I'm thinking it would if you also had good selection keybindings.
click on node -> select-family -> command-x (family gets highlighted similar to Excel) -> select target node -> use sibling or append-child (implicitely moves the family in the clipboard)
The only other special move you need is a switch-position between siblings. for the insert actions it would be best to have next-sibling and previous-sibling (alt-arrow left/right like iWorks tables?) and last/first child.
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.
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 or less), which is easy for text. But as soon as you want to move to useful, common tree-structures, you have to agree on both representation and semantics, which makes it much harder.
One challenge we need to solve is - what level do you want to work on? Let's say you're working on some code. You may want to treat functions and blocks as a tree structure, but you want to treat simple mathematical expressions as text. Where this threshold is, is entirely context-dependent. The editor needs to understand the language and be able to expand text into its tree structure, or collapse the tree into its text representation, at any node in the tree.
This implies that we need to agree on a common format for defining the conversion (parsing and generating) between text and trees. We'd probably also need a package system which contains common definitions for all major languages.
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.
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 Representation System, with each node being a collection of data, with two special data types, one called a "frame" that contains logic and references to the other fields of the node, and one called a "reference" that pointed to a "frame" of some other node. All very basic, as the end-users were not programmers but financial analysts. Due to the freeform intended usage, the UI was on a vector monitor (like the old Asteroids arcade game), and end-users were trained to use the system as a collection of notes they can freeform write anywhere about their job, with little formulas to calculate things within a note and between other notes. It was explained to be like a combination notepad and spreadsheet. And it made a lot of sense to the end-users; they quickly got elaborate with their logic. The UI got zooming capabilities so actively edited or evaluated nodes would scale up while others shrank down, the end-users kept asking for more sophisticated features, and it really looked like we were on to something BIG. During an evaluation of the project with other professors, one of them asked "Once you've completed these requested features from your financial analysts, haven't you recreated just another programming language? The UI is unique, but I'm just seeing an interpreted language and a metaphor for programming that works with your finance end-users." ...And he was right.
I turned the project into another independent study and created a 3D animation language. About a decade later, I was introduced to the first feature film compositor centered around the GPU, called Shake, and it's node layout looked creepily familiar to how the Frame Knowledge System was when I last used it...
While we might have some common idea what is text, we definitely not have common semantics! The resulting situation isn't so much different from trees.
And what do you mean by "s-expressions just too simple"? Isn't simplicity something to strive for?
> While we might have some common idea what is text, we definitely not have common semantics!
Funny, that makes me think of the new Wikitext editor that the Wikimedia Foundation is developing. [1]
They are using the previous Visual editor infrastructure, and they are having problems because features that make sense for a rich text editor are creeping into the plain-text code editor (such as unwanted copy-pasting of styling code).
> And what do you mean by "s-expressions just too simple"? Isn't simplicity something to strive for?
I should stress "a bit". Actually, looking closer at s-expressions right now (I was writing based on what I remembered), I'd like to flip that statement. S-expressions are just a bit more complex than what I have in mind. Or alternately: they're equivalent under some trivial transformation.
It depends on how you look at things - there are supposedly many different implementations of s-expressions, which support different fundamental data types. The basic idea is simpler. There are no fundamental data types, just nodes. For example a 'bit' is a node which can contain one of two child nodes ('one' or 'zero'). Any tree which represents data in memory on a computer can be expanded down to a collection of bits. Though in a text representation or tree editor the user will generally have collapsed the tree such that they don't see individual bits.
What I have in mind could look more complex than s-expression in a different context though: the text file representation of the trees may have more syntactic sugar than s-expressions in lisp.
The representation isn't significantly different, but the focus is. I'm focusing more on things related to type theory, schemas, how to represent patches/diffs, standardizing parsing/generation and other transforms, etc.
I have reread your text several times, and don't get it. What do you gain by having no fundamental datatypes, only bits? What syntactical sugar is not expressible by s-expression + transformation rules?
I am working on something like that too, and I'm completely fine with symbols (with their arbitrary definition by lisp and user) being the fundamental elements.
> What do you gain by having no fundamental datatypes, only bits?
I'd say what you gain is reusability, mostly. When you impose a datatype on data, it comes with a series of constraints and expectations, so you can only use the data in the ways prescribed by its type.
If the data doesn't have attached a type of is own, you can use it in different ways at different contexts - this can be valuable for data transformation processes, such as compilation or system interfaces. I suppose you could get the same effect by casting the data to a new type when you change it to a new context.
I've read a bunch about applying semiotics theory to programming, and changing the meaning of the symbols "on the go" is closer to the way we think (inferring meanings from the signs adequate to the current context) than the old mathematical approach of "every datum has one well-defined type, and only one".
You must have read about Urbit, right? Their VM's underlying language/bytecode/thing, Nock, is based on nested pairs of natural numbers, which is perhaps only slightly less unwieldy than operating on single bits.
PS, if you're as enthusiastic about this idea as I am, we should talk, can I email you?
I think it could be neat if the spec of the s-exp was read from local hints rather than top-down prescription. You could show a color picker for color argument to a function etc. clojure.spec seems a cool tool.
>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.
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.
I think what you're describing almost exists for C++ in the form of libclang. Editors really prize uniformity and predictability, to give users a comfortable experience, which is why I think libclang is so unwieldy if you try to integrate it into an editor fully—I tried with emacs once. So, despite all the massive effort put into clang, it gets incorporated piecemeal, one IDE feature at a time.
You should look at JetBrains MPS, as should everyone posting on this thread. Because MPS has been in development for over 10 years as far as I know, and has attacked and solved a huge number of the issues you raise here and many more too (e.g. how to integrate non-text based programming with version control).
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...).
I use org mode every day. It actually is a tree editor. You can fold and unfold entries, move whole subtrees into deeper/higher levels, etc. The tree editor however is just one of many org features.
I'm using yEd a lot, and I especially like layouting functions like hierarchical layout. I often use it to plan interdependent tasks. I just start with tasks I know are required and the thing of their prerequisites. Quite fast this gives a big graph structure. Then I run a hierarchical layout on this and suddenly I have a very clear structure of tasks. Their hierarchical layouting algorithm is great. I suspect it may be based on GraphViz dot's algorithm (http://www.graphviz.org/Documentation/TSE93.pdf) as it produces results of similar high quality.
I also love the UI of yEd. Zooming in and out, creating nodes and dependencies/edges feels just great.
221 comments
[ 2.8 ms ] story [ 323 ms ] threadhttps://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
By comparison, the Emacs Wiki article is a poor introduction, because introduction is not its purpose; it's there to collect resources for people who already use paredit, and a good introduction answers the question of why someonr would want to start.
That said, thanks so much for posting about it here! I'm really looking forward to learning it today.
https://youtube.com/watch?v=D6h5dFyyUX0
I've never used it and I'm genuinely curious.
If I was working on lisp-like languages, I would definitely use it. But ParEdit didn't stick to me, even after a few attempts. I didn't like the key bindings, and I think that the interface is too complex for me.
Also, there are alternatives. What do you think about them?
Not sure what it is like for other tree structures.
[0]https://www.yworks.com/products/yed
I pretty much just use indented text trees for all but the most complex parts of software design and I find it works very well.
You mean points and sub-points?
>all but the most complex parts
And what do you use for those?
1. Nobody knows what it should look like.
2. Nobody knows how it should work.
I fear this article has left me as much in the dark on these points as I was before I read it. Perhaps someone else here will find something in it I missed.
There is a gaping hole in the market.
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.
[0]: http://lamport.azurewebsites.net/pubs/proof.pdf
https://github.com/YaakovDavis/TreeSlides
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?
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.
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?
Without having to read anything you just have to remember to use * to mark sections and * * for subsections and so on. Then you use tab to expand/collapse the sections. That's rather intuitive, not more complicated than a plain text file and already you have better highlighting and additional functionality.
Then sometimes I wonder "hey, I'd like to have a link to this URL in this file" or "I'd like to export this to HTML or PDF so that I can send it to my friend who doesn't use org-mode without losing the formatting". And then you look in the manual and you (generally) find what you're looking for.
Sure if you want to be an org-mode wizard you'll have to learn quite a bit but I really don't see "the complexity penalty vs. using a plain text file". The complexity is only here if you want it.
Edit: also the array auto-formatting is a godsend. Doing it by hand in text files is tedious.
[1]: http://strlen.com/treesheets/docs/screenshots.html
https://gingkoapp.com/
Used it at university for notes, and is great for quick revisions before the exams too!
1. https://en.wikipedia.org/wiki/PIM
Also, supports LaTeX.
Yeah, Gingko is really phenomenal, especially for multiplayer!
Joke aside, graphs are far from being trivial to represent as a data structure, and their use are so various that you can hardly edit a graph using text alone. Even a visual editor would require to be tailored to different work you do with graphs.
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 tree browser, works like filesystem browser - you can open "folders" (nodes with subnodes) and "files" (leaf nodes). Each node shows specific editor for it's type, that usually consist of few form fields.
I couldn't get the full 14 level tree to fit on my screen.
You can build your own admin UI, if you want as it's all done with the same API you use to build your sites.
[0] http://websitebaker.org/
I mean, I like the idea a lot! Used MindNode, but I found it very bound to specific type of problems. It is visualization tool. And Emacs is just too much. I use it from time to time, but I would like nice native general purpose text editor with Tree capability and Markdown support.
I'm asking this on the perspective of someone who is about to teach model-driven software engineering for a semester but cannot find much pratical use for it..
More than tree structured XML, this also provides node graph XML visual editing.
Like OP mentions Excel for instance, for editing tabular data, which isn't quite a standard file format, and in any case supports many different formats for tabular data.
I can't help but wonder if OP is focusing on "format" rather than the structure of the data itself. There's plenty of editors for these well known formats. Perhaps he just needs to restructure his problem to use one of these?
In XML for instance, it's fairly straightforward to implement a "plugin" such as he describes, using python or ruby and a DOM parser, which could amongst other things provide the different renderings described.
I remember using XML Spy a long time back which seemed to do this quite well, as an ever expanding grid of cells, click into a cell, and it would expand showing its constituent cells. There were different tree representations available as well.
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
I use Mathematica, and I just use the plaintext Mathematica syntax for large equations too. I also break these into multiple lines.
I understand how to indent TeX, but when you have a hundred algebraic terms it's very unwieldly, and Mathematica becomes clearly superior (for me) just to visualize it.
Anyways, it sounds like you're just saying you haven't found the graphical visualization for equation trees to be useful, so you stick with the linear representation, but the manipulations of those trees (by mathematica, or some other dedicated editor) is still useful.
In this case I would add that we would probably still need some sort of visualization aid for sufficiently large equations, and that the tools are just not good right now. After all, much/most code is written in normal (linear) text editors, but some people still do find it useful to "collapse" sections of code, corresponding to branches of the tree structure induced by indentation. Many people don't bother with this right now because it can cause headaches that simple scrolling does not, but better tools may change this.
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.
click on node -> select-family -> command-x (family gets highlighted similar to Excel) -> select target node -> use sibling or append-child (implicitely moves the family in the clipboard)
The only other special move you need is a switch-position between siblings. for the insert actions it would be best to have next-sibling and previous-sibling (alt-arrow left/right like iWorks tables?) and last/first child.
> Gephi is an award-winning open-source platform for visualizing and manipulating large graphs.
- Update your profile.
- Post Tweets for you.
That's not cool.
http://littleoutliner.com/v1/
It saves a single document in your browser's local storage.
https://github.com/interstar/OWL
Good stuff.
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 or less), which is easy for text. But as soon as you want to move to useful, common tree-structures, you have to agree on both representation and semantics, which makes it much harder.
One challenge we need to solve is - what level do you want to work on? Let's say you're working on some code. You may want to treat functions and blocks as a tree structure, but you want to treat simple mathematical expressions as text. Where this threshold is, is entirely context-dependent. The editor needs to understand the language and be able to expand text into its tree structure, or collapse the tree into its text representation, at any node in the tree.
This implies that we need to agree on a common format for defining the conversion (parsing and generating) between text and trees. We'd probably also need a package system which contains common definitions for all major languages.
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...
And what do you mean by "s-expressions just too simple"? Isn't simplicity something to strive for?
Funny, that makes me think of the new Wikitext editor that the Wikimedia Foundation is developing. [1]
They are using the previous Visual editor infrastructure, and they are having problems because features that make sense for a rich text editor are creeping into the plain-text code editor (such as unwanted copy-pasting of styling code).
[1] https://www.mediawiki.org/wiki/2017_wikitext_editor
I should stress "a bit". Actually, looking closer at s-expressions right now (I was writing based on what I remembered), I'd like to flip that statement. S-expressions are just a bit more complex than what I have in mind. Or alternately: they're equivalent under some trivial transformation.
It depends on how you look at things - there are supposedly many different implementations of s-expressions, which support different fundamental data types. The basic idea is simpler. There are no fundamental data types, just nodes. For example a 'bit' is a node which can contain one of two child nodes ('one' or 'zero'). Any tree which represents data in memory on a computer can be expanded down to a collection of bits. Though in a text representation or tree editor the user will generally have collapsed the tree such that they don't see individual bits.
What I have in mind could look more complex than s-expression in a different context though: the text file representation of the trees may have more syntactic sugar than s-expressions in lisp.
The representation isn't significantly different, but the focus is. I'm focusing more on things related to type theory, schemas, how to represent patches/diffs, standardizing parsing/generation and other transforms, etc.
I am working on something like that too, and I'm completely fine with symbols (with their arbitrary definition by lisp and user) being the fundamental elements.
I'd say what you gain is reusability, mostly. When you impose a datatype on data, it comes with a series of constraints and expectations, so you can only use the data in the ways prescribed by its type.
If the data doesn't have attached a type of is own, you can use it in different ways at different contexts - this can be valuable for data transformation processes, such as compilation or system interfaces. I suppose you could get the same effect by casting the data to a new type when you change it to a new context.
I've read a bunch about applying semiotics theory to programming, and changing the meaning of the symbols "on the go" is closer to the way we think (inferring meanings from the signs adequate to the current context) than the old mathematical approach of "every datum has one well-defined type, and only one".
PS, if you're as enthusiastic about this idea as I am, we should talk, can I email you?
Ummm json??
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.
E.g.
http://jsoneditoronline.org/
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...).
Emacs with IMHO better keybindings, lots of integrated packages which can be switched on/off as functionally related "layers".
For vim users has of course evil package.
[0] http://spacemacs.org/
I'm using yEd a lot, and I especially like layouting functions like hierarchical layout. I often use it to plan interdependent tasks. I just start with tasks I know are required and the thing of their prerequisites. Quite fast this gives a big graph structure. Then I run a hierarchical layout on this and suddenly I have a very clear structure of tasks. Their hierarchical layouting algorithm is great. I suspect it may be based on GraphViz dot's algorithm (http://www.graphviz.org/Documentation/TSE93.pdf) as it produces results of similar high quality.
I also love the UI of yEd. Zooming in and out, creating nodes and dependencies/edges feels just great.
It's only for JSON but you can write a small script to convert it to whatever format you want.