Backstory - I started experimenting with AST editing ideas after getting frustrated with my editor's lack of understanding of the structure and meaning of code, ie. the editing primitives all dealt with text and simple changes to the code often required repetitive manual text edits that had nothing to do with the meaning of the change. I went through a couple of prototypes and landed on the idea of augmenting a standard editing interface with a new mode that works on a simplified representation of the structure, which basically follows indentation levels - blocks of code like functions, loops, etc, can be moved and manipulated as units, and there are specific editing commands for the different elements.<p>The main idea is to design all of the editing and navigation commands around the thought processes (instead of designing around a data structure, which I think is where traditional editors have gone wrong), so that it feels natural and intuitive to use - like something that's been designed for what editing code actually involves, as opposed to a text editor that's had lots of code intelligence stuff added on top of it.
I wrote a tree editor for programs for my Master's thesis, in 1980. You can get it at <a href="https://www.cs.toronto.edu/~radford/MSc-thesis.abstract.html" rel="nofollow">https://www.cs.toronto.edu/~radford/MSc-thesis.abstract.html</a><p>The editor operates on the AST down to the lowest level, with careful design of keyboard input and cursor feedback to make that not too painful for things like infix operators. The language is described by a grammar, and there is an AST macro language.<p>My conclusion afterwards was that the shift at that time away from keyboard input towards editing with a mouse was negative for editing in terms of the AST (rather than text), since with AST editing there's a less direct connection between seeing and pointing and what you're editing. I got interested in other things.<p>But perhaps that was a premature conclusion.
An explanation of what AST actually means would be helpful at the top of the intro page. Quite of a few of the selling points were lost on me due to lack of familiarity with the term. I can (and will) google it, but if I am looking at a new product, especially one I have to buy, it'd be nice to have the resources available to understand what it offers without turning to a third party.
Interesting, there's been an [ongoing discussion to use tree-sitter with Emacs](<a href="https://archive.casouri.cat/note/2021/emacs-tree-sitter/index.html" rel="nofollow">https://archive.casouri.cat/note/2021/emacs-tree-sitter/inde...</a>) because right now, syntax highlighting is a mix of regex and functions.<p>I don't how language parsing should be exposed to make it easy to have parsing in editors. But I believe some efforts like tree-sitter are most welcome and also more inline with what we expect editors to be.
There has been a movement to try something like this under the buzzword "projectional editing". The idea was to edit a representation of the code and not the code itself. People and companies experimented with it but didn't get much adoption. Not sure why.<p>Perhaps you need to allow the developers to reach invalid states, because the editors I tried just refused entries which would result in a syntax violation. This is harder to implement though. :)
I vaguely remember someone telling me, a long time ago, that Thomas Reps' PhD thesis<p>(<a href="https://ieeexplore.ieee.org/book/6267325" rel="nofollow">https://ieeexplore.ieee.org/book/6267325</a>)<p>showed that it wasn't practical to build this kind of editor.
Perhaps that was not at all the point; it was a long time ago.<p>I wonder, though, can anyone explain 1) if Reps' thesis does bear on the Treefrog work 2) what it was in Reps' thesis that bears on the difficulty of making syntax-tree based code development tools?
The S,D shortcuts work for me, but I can't get J or K to do anything? Some UX feedback on what is valid at the current time may be useful. One problem with structural/projection editors is it's not as clear what is a valid operation in the current state.<p>There's some existing work in this area you might find interesting as well:<p><a href="https://twitter.com/dm_0ney/status/1414742742530498566" rel="nofollow">https://twitter.com/dm_0ney/status/1414742742530498566</a><p><a href="https://hazel.org/" rel="nofollow">https://hazel.org/</a><p><a href="https://hazel.org/build/dev/" rel="nofollow">https://hazel.org/build/dev/</a> (expand the left side pane by clicking the (?) to see the valid operations)
Clever line of thinking.<p>Is it fair to think of IDEs that include language-specific refactoring capabilities as a providing a developer abstraction over AST editing?
Some feedback on the actual implementation:<p>- I cannot reach inside if and while statements using tree mode<p>- It is not clear which lines are available for refactorings<p>- dragging a line reveals "+ If" and "+ else if" under an if statement. Dropping the line onto it does not work.<p>- tree based moving does not move the viewport<p>About the business side of it:<p>I think it will be hard to create a whole editor just for these features. I know that Jetbrains editors also have ast aware refactorings and I often use moveBySymbol in sublime text which acts a lot like your tree navigation. I think it makes more sense to create this as a plugin, but it will be difficult to monetize that.<p>Anyway I applaud you for creating something that actually works!
The features I've always dreamed about from an AST aware editor was shell-like functionality where operations to rename, move, copy, create, etc were akin to file manipulations done on the command line. At one point I was thinking about the possibility of FUSE-ifying(<a href="https://en.wikipedia.org/wiki/Filesystem_in_Userspace" rel="nofollow">https://en.wikipedia.org/wiki/Filesystem_in_Userspace</a>) some code so that a normal shell could be used. Any chance of shell-like functionality from treefrog?
The text in the editor is blurry - looks like it's rendered at a lower resolution, and then upscaled with bilinear filtering.<p>(This is on a 4K display running Win11 with UI scale set to 200%)
One pet peeve of mine that this kind of editor might be able to address is how live compilation is sketchy when you're actively editing a file. For example when you're in the middle of an edit and you end up with a huge number of compilation errors because the parse of the file is in flux. Having the editor and the syntax parser aware of each other can help fix such issues.<p>Semantic merging would also be a nice feature.
The scroll is really hard to use on my macbook. I can't scroll slowly enough. It moves massively up and down with each scroll even when I am very careful.