I feel so illiterate when it comes to AST editing sometimes. I understand what an AST is from a computer science perspective. But I've never worked on a huge software refactor before that required direct AST textobject editing. Maybe an indication of my skill level...
The extent of my usage is having nice textobjects to easily interact with arglists and functions which aren't native to (neo)vim. Very cute and nice to just write "daf" somewhere in a function and just have it "just delete". Or hook it up with basic macros: search for regex, "daf".
I guess it's hard for me to edit things that I don't see right in front of me or aren't super simple changes (like name changes). Or at least, basic things I can reason about (such as finding by regex then deleting by textobject or something).
As for LSP's, I do use go to definition and rename all references, which is nice. But the huge structural refactoring part I have never really done. I don't really use many LSP features besides those two either...
Basically, I gotta up my editor game.
In my classification of editors:
1. Orthodox. Mostly focused on looks and integrations.
2. Modal, Vim improvement. Focus on keeping basic Vim keybindings with minor improvements.
3. Modal, rethinking Vim approach.
Ki falls into the third category which I constantly monitor.
I can't wait to try it. Love that it's keyboard layout agnostic. A lot of other good sounding ideas in the docs. Especially inspiration from Emacs as everything being an editable buffer. There's always some massive tradeoffs between editors though. Guess I'll have to see.
I made the vscode integration for this. I feel bad that I haven’t contributed much since, it’s a really cool project. IMO it’s important to try to innovate in the foundational tools of our craft (editors, languages, tooling, OS, etc) which Ki does.
I didn't fully understand until I saw the examples
> First-class syntactic modification
> Notice the comma between the current and the next node is also deleted. > Notice how comma is added automatically.
This is awesome! And I bet it arguably requires less logic to do so as well. Cool stuff.
Now I'm wondering how much effort it would be to get a ki integration (or at least an AST-first rewrite) in Zed
This is like slurp, barf, splice, raise, kill, cut, yank for lisps.
I don't like the positional keybindings. There is no real difference from regular keybindings configured with profiles for Qwerty, Dvorak, etc. In practice, it just means presenting them drawn into keyboards in a way that is hard to quickly search or use in the terminal and anywhere really. Where's the "line" key? Search the drawing! (Oh... it is there in th top left corner, but which exact key?) I prefer a list. So, really, it is not even that big of a "special thing" except the presentation.
First impression. Muscle memory is a problem :(
Vim's j moves down.
Ki's j in line mode moves up...
There was some Show HN some weeks ago on VCS/diff that operates on AST instead of lines/chars, anyone remembers its name?
Vim-like (terminal and VSCode extension) that prioritizes syntax-based navigation.
Comparison to Vim and Helix: https://ki-editor.org/docs/comparison#user-content-fn-1
Does it support C++?
Have you seen any of the lisp tree editing modes for eMacs or vim?
[dead]
The "First-class syntactic selection" reminds me of my most used shortcut(s) in Jetbrains IDEs: the Expand / Shrink Selection.
https://www.jetbrains.com/help/idea/working-with-source-code...It really changed my perspective on interacting with the 'text' of a file.
VS Code, Zed, etc. have similar operations, but in my experience they expand and shrink too coarsely.