I came across this on reddit and took a closer look and thought it had some interesting ideas. It’s called sapling and is based on some ideas presented in this blog article. It wants to replace editing text with editing an AST. It’s written in rust, and is being live coded on Saturdays on YouTube.
I’ve seen some discussion on this forum about tree-sitter and making selections and highlighting and such more semantically driven, but this goes a step further and replaces all editing primitives to work on an AST which gets later turned into a text file on save.
Personally I have some doubts about this approach, but love seeing new work in the area of making editors smarter without adding enormous computational work to get it there.
Anyway I thought people on this forum might be interested in giving a watch or at least playing around with some of the ideas.
7 Likes
Thank you for sharing this. It certainly seems like an interesting concept, directly editing an AST rather than textual code. I also have doubts about this approach, but it’s incredibly interesting and I bet that regardless of whether sapling succeeds or fails, there’s going to be some interesting concepts explored and lessons learned.
Definitely interesting and can’t wait to see where his experiments will lead.
In the article there’s one paragraph which resonates with Kakoune:
A cursor only makes sense for inserting
This is something that I think is obvious now I’ve realised it, but because of its universal use, I hadn’t considered before.
Why do I need a cursor while I’m viewing/moving/deleting code?
[…]
I feel like Kakoune somehow follows this mantra with the concept “it’s not a cursor, but a selection of 1 character”
But then the article expand a further concepts like “narrowing” or “buffer portal”, that go beyond the simple “selections color-highlighting” we have right now in Kakoune. For example when having 2 sentences selected, one at the start and the end of a long buffer that does not fit on a screen, it would make sense to be able to visualize both of them at the same time on a temporary virtual buffer. (a bit like incsearch=split does in Neovim)
But back to the core AST concept described, I experimented in the past with a similar approach for JavaScript https://github.com/Delapouite/kakoune-grasp and the results were often “good enough”.
2 Likes
That’s a pretty cool idea!
Got my gears turning about how one could dynamically recognize raw text format and apply appropriate parser to generate semantic data structure. Such engine could work independently from editor/frontend and would handle reading, writing and manipulating of the abstract data structure.
2 Likes
In a soon to be merged PR, the README now mentions Kakoune: Give the README some TLC by kneasle · Pull Request #29 · kneasle/sapling · GitHub
Shoutout in particular to Kakoune for its beautiful multi-selection based editing model.
5 Likes
I am definitely interested in structural editing in kakoune, and https://github.com/ul/kak-tree was an big source of inspiration for how it might work out in practice.
Setting aside random bugs, my issue was that I had a really hard time anticipating what the next enclosing syntax scope was in C++. I’m dabbling around to see if I can make a solution for myself.
One idea that I had was that something like rainbow parens could be used as a visual indicator of available scopes. Alternatively, maybe expanding the mapping to be more language specific, like next function body independently of other structures would be more appropriate.