111–120 of 222 posts
Check gingko, which is more focussed on docs, but is a tree editor at its core. https://gingkoapp.com/ Used it at university for notes, and is great for quick revisions before the exams too!
Earlier quoted context omitted.
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?
> 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…
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.
Not the most complex solution but also super easy to use. Tab to indent, shift-tab to unindent. Select-drag-and-drop... etc.
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…
Little Outliner 2 is pretty good. http://littleoutliner.com/ Made by Dave @ scripting.com
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…
Earlier quoted context omitted.
>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. Ummm json??
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.
E.g.
Workflowy is pretty nice, it exports to plain text and xml. https://workflowy.com/
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
It also has org-mode which seems fairly similar, but offers additional (optional) features for doing things like tables and due dates within the tree. 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?
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" can be discarded, since a general tree editor should allow arbitrary edits to arbitrary trees (in the same way that a general text editor should allow any text to be inserted anywhere in a file/buffer). Plugins can add it back for particular languages.
- Nesting should be the only relationship; it subsumes "sitting beside" (like Blockly assignments) or "wrapping around" (blockly loops).
- No need to distinguish between editable/immutable values; everything is editable.
As a baby step towards the author's goal, how about an s-expression editor which displays boxes-in-boxes instead of parentheses? The editing commands could be exactly the same as e.g. Emacs+paredit, the only difference would be that indentation begins at the left edge of the current box, rather than at the left edge of the screen. For example, we would have to discard the indentation of an expression like:
(foo (bar baz) (quux
foobar))
+-------------------------+
| +-------+ +---------+|
|foo |bar baz| |quux ||
| +-------+ | foobar||
| +---------+|
+-------------------------+
More radical extensions can then support pulling the boxes out into a more traditional tree structure.