3 ms·

I think it's important to distinguish between "tree-structured data" and "tree-structured UI"; many of the suggestions here and in the article's comments mentio

I think it's important to distinguish between "tree-structured data" and "tree-structured UI"; many of the suggestions here and in the article's comments mention s-expressions (or alternatives e.g. using indentation or similar); many others mention diagramming/mindmapping tools. I think the real issue is how disconnected such approaches are from each other: why can't I press a key and have my parenthesised expression be expanded into a tree, or press another button to collapse a sub-tree down into a parenthesised expression? I imagine a decent tree editor would let me: - Navigate and edit the structure and its contents in a linear representation, like using paredit on an s-expression. - Navigate and edit the structure and its contents in a more "tree-like" representation, e.g. as boxes+arrows, or nested boxes. - Toggle between display modes on a per-term basis, e.g. using boxes+arrows for the top-level (say, function definitions in a Lisp file) and s-expressions for the contents. - Fold/unfold terms/trees (code folding, but for expressions rather than lines) - Allow plugins/preferences tailored for particular trees, e.g. syntax colouring for programming language parse trees. As a more elaborate idea, we could allow plugins to extend the tree/graph structure with "virtual" nodes, e.g. linking names to their definitions, documentation, tests, etc. as if they were code-folded parts of the source code.

junke 10y ago
> Fold/unfold terms/trees (code folding, but for expressions rather than lines) Emacs can hide/show blocks in Lisp expressions (and others). Install HideShow (https://www.emacswiki.org/emacs/HideShow https://www.emacswiki.org/emacs/HideShow). I personally never use it, generally the right solution is to refactor (but there might be good use cases too). > As a more elaborate idea, we could allow plugins to extend the tree/graph structure with "virtual" nodes, e.g. linking names to their definitions, documentation, tests, etc. as if they were code-folded parts of the source code. Basically, when working from Emacs through Slime, the Common Lisp backend (called Swank) injects such metadata to the runtime objects (source file if a file exists, original code, documentation). You could define your very own properties if you want, like how a particular form should be displayed to the user. What already exists, for example, is a way to define custom indentation rules for macros, which are used on the Emacs side to indent your code as you wish. Slime also decorates values in the buffer so that they act as "presentation" objects (https://www.common-lisp.net/project/slime/doc/html/Presentations.html https://www.common-lisp.net/project/slime/doc/html/Presentat...).
- chriswarbo 10y ago
  > Emacs can hide/show blocks in Lisp expressions (and others). Install HideShow (https://www.emacswiki.org/emacs/HideShow https://www.emacswiki.org/emacs/HideShow). Yes, I've used it before and it's quite nice. I've not used Slime, or done any Common Lisp programming for that matter. I do love Emacs, and calling out to a sub/inferior-process for language-specific info is a good idea; it can just be frustrating to actually get the darn things to work though. After failing to get Geiser to work for Racket, or ghc-mod || intero || dante for Haskell, I've resigned myself to being happy with just syntax colouring :(

junke 10y ago

> Fold/unfold terms/trees (code folding, but for expressions rather than lines) Emacs can hide/show blocks in Lisp expressions (and others). Install HideShow (https://www.emacswiki.org/emacs/HideShow https://www.emacswiki.org/emacs/HideShow). I personally never use it, generally the right solution is to refactor (but there might be good use cases too). > As a more elaborate idea, we could allow plugins to extend the tree/graph structure with "virtual" nodes, e.g. linking names to their definitions, documentation, tests, etc. as if they were code-folded parts of the source code. Basically, when working from Emacs through Slime, the Common Lisp backend (called Swank) injects such metadata to the runtime objects (source file if a file exists, original code, documentation). You could define your very own properties if you want, like how a particular form should be displayed to the user. What already exists, for example, is a way to define custom indentation rules for macros, which are used on the Emacs side to indent your code as you wish. Slime also decorates values in the buffer so that they act as "presentation" objects (https://www.common-lisp.net/project/slime/doc/html/Presentations.html https://www.common-lisp.net/project/slime/doc/html/Presentat...).

chriswarbo 10y ago
> Emacs can hide/show blocks in Lisp expressions (and others). Install HideShow (https://www.emacswiki.org/emacs/HideShow https://www.emacswiki.org/emacs/HideShow). Yes, I've used it before and it's quite nice. I've not used Slime, or done any Common Lisp programming for that matter. I do love Emacs, and calling out to a sub/inferior-process for language-specific info is a good idea; it can just be frustrating to actually get the darn things to work though. After failing to get Geiser to work for Racket, or ghc-mod || intero || dante for Haskell, I've resigned myself to being happy with just syntax colouring :(