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...
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.
Hold on. Operating systems and long-running esoteric history are always on topic here, right?
(This is spoken with something close to affection; I look fondly on my former Emacs days. I'm probably more likely than not to enjoy the company of a human who has at least tried Emacs and had some thoughtful reaction to it. I may not use it now but the ideas live on in how I think and what I expect. Editors that push the limits, whatever those limits are, are part of the old school ethos I love about programming.)
I am working on a modal code editor project that you might find interesting then. It also operates on an AST directly, which is represented as UI nodes which closely resemble normal text layout. Email in profile if you’d like to give it a try and possibly give early feedback (still in early development).
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.
That comparison table is strange and sometimes wrong. Neovim for example detects and updates external file changes by default. And the coherence of the keybindings in Ki is "Great" bit vim/helix:
> As you can see, there's no single logical categorization for these keymaps, they are either lowercase-uppercase, normal-alt, left-right bracket, or outright unexplainable.
Word, End, Back, Change Word and even Change Inner (, etc are very logical to me and I feel like I'm talking to the editor when editing. I get that it doesn't make sense when one has learned another way to do it, but it does make total sense you just have to make an effort to try and understand it.
It's like learning and always driving automatic then calling manual "outright unexplainable". You simply learned another way and are conditioned into believing that's the one true way. It shows the creator comes from VSCode (multi-cursor is a useless feature, just use s/search/replace and get used to macros and a whole new world will open).
I think you've touched on it, but I'm going try to take it one step further into explicitness.
Just over a year ago I decided to switch to Neovim. The reason for switching was personal; I was struggling with what I'll call "clutter" in other tools and I wanted a tool that would reinforce, at least lightly, a mode of working that promoted focus on what I was working on, while making it easy to reference other files without loading up my editor with tabs and other visual clutter (buttons/menus) I don't care about most of the time.
I took the advice I seemed to bump into repeatedly: try out vim mode in my current editor before making the plunge.
I really struggled at first. It felt wildly foreign. All the shortcuts were nowhere near to the world I was familiar with.
As I was about to give up, I ran into some advice that was along the lines of "stop trying to memorize shortcuts and start thinking in terms of what you want to achieve" (words and motions in vim-speak).
Your example of [C]hange [I]nner is a great one; that one in particular was life changing. Sure there are some words and motions that do require memorization, but so many others just flow naturally. And once you start thinking in actions, it's easy to see how they can layer on top of each other in really elegant ways.
I'm not even here trying to tout vim-like editors, I'd wager there are many editors that have some semblance of this kind of interaction, but rather to reiterate there's a shift from a PoV of function vs. goal.
Again, I don't think this is "the right way" but rather one of many perspectives that works in context with the phenomenology of me.
I still think their point about search and replace still stand though. I make most my edits with regex in neovim nowadays and I feel this is the superior paradigm: You don't even need to get to some specific location in order to edit it. I also almost only use search to move around the file and I can even reuse the searches for substitutions. It makes most vim motions and commands almost useless for me nowadays.
I also feel like macros are a more clunky and error prone way to do that substitutions can do. Almost never use them.
> I was a Neovim macro user until I figured out how insane that was compared to multi-cursor after using Helix.
Multi-cursor was the first plugin I installed when I moved from VSCode to Vim because I was used to hitting Ctrl+d to select all words and then replacing. Does Helix do something different?
1) First I reach for <C-v> for visual block selection if everything is neatly aligned.
2) Next choice is %s/search/replace(/c if I need confirm).
3) Macros, and I love it everytime I get to use them. I just record the movements, copy what I need to copy, paste it where I need to paste it, and it's repeatable for every line or block where the *formatting* matches. And this is the important part, the words don't matter. I still feel like a wizard using them.
As far as I understand multi-cursor option 3 is a no-go without macros if the words don't match. But macros don't care as long as the movements translate to the same edits. How does Helix multi-cursor work that make macros insane?
Sorry for derailing a bit, the search and replace using a query make sense for purly textual (non-syntactic) editing, but if you want to apply consistent syntactic modifications across multiple locations in the same file, you will need both multi-cursor and syntax node selection/navigation/modification.
It's hard to explain unless you actually try Ki, because it is a paradigm shift
I had an experience like this when I switched to a Keyboardio split keyboard. It was impossible to use at first. Then I do some deliberate practice with a typing tutor app and now I love it so much I own multiple.
Is there a good tutorial for some of these advanced text editing features?
In particular I’d like to get platform independent shortcuts / key bindings. I use both windows and MacOS daily, and it throws off my muscle memory for shortcuts like “go to beginning of line”
> Note that the Ki keybindings cannot be simply implemented in Vim/Helix via key- remapping, due to the lack of the concept of Selection Mode, and implementing that requires major architectural changes in the core.
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.
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.
Also available as `incremental selection` in Neovim via tree-sitter.
I agree, top feature. Combined with things like "extract method" makes mundane refactorings super fast.
This has got to be my favourite feature of IntelliJ, along with the dumb context actions menu
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
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.
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.
4. All of the above.
Which is Emacs.
Right, but we are discussing editors here.
Hold on. Operating systems and long-running esoteric history are always on topic here, right?
(This is spoken with something close to affection; I look fondly on my former Emacs days. I'm probably more likely than not to enjoy the company of a human who has at least tried Emacs and had some thoughtful reaction to it. I may not use it now but the ideas live on in how I think and what I expect. Editors that push the limits, whatever those limits are, are part of the old school ethos I love about programming.)
I know, I use Emacs+Evil. I'm going to give Ki a try and, in case of success, to think about writing Ki binding for Emacs.
emacs already has structural editing packages like combobulate
This is the first time I've heard about Emacs trying to look nice.
Vim is Emacs applied to Vi
I am working on a modal code editor project that you might find interesting then. It also operates on an AST directly, which is represented as UI nodes which closely resemble normal text layout. Email in profile if you’d like to give it a try and possibly give early feedback (still in early development).
Exactly the same for me. So far, there have been many challengers but the same champion (subjective, I know).
Vim improvement
So Ed Visual Mode Improved Improved!
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'll wait till an Emacs package is available
https://github.com/mickeynp/combobulate
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
That comparison table is strange and sometimes wrong. Neovim for example detects and updates external file changes by default. And the coherence of the keybindings in Ki is "Great" bit vim/helix:
> As you can see, there's no single logical categorization for these keymaps, they are either lowercase-uppercase, normal-alt, left-right bracket, or outright unexplainable.
Word, End, Back, Change Word and even Change Inner (, etc are very logical to me and I feel like I'm talking to the editor when editing. I get that it doesn't make sense when one has learned another way to do it, but it does make total sense you just have to make an effort to try and understand it.
It's like learning and always driving automatic then calling manual "outright unexplainable". You simply learned another way and are conditioned into believing that's the one true way. It shows the creator comes from VSCode (multi-cursor is a useless feature, just use s/search/replace and get used to macros and a whole new world will open).
I think you've touched on it, but I'm going try to take it one step further into explicitness.
Just over a year ago I decided to switch to Neovim. The reason for switching was personal; I was struggling with what I'll call "clutter" in other tools and I wanted a tool that would reinforce, at least lightly, a mode of working that promoted focus on what I was working on, while making it easy to reference other files without loading up my editor with tabs and other visual clutter (buttons/menus) I don't care about most of the time.
I took the advice I seemed to bump into repeatedly: try out vim mode in my current editor before making the plunge.
I really struggled at first. It felt wildly foreign. All the shortcuts were nowhere near to the world I was familiar with.
As I was about to give up, I ran into some advice that was along the lines of "stop trying to memorize shortcuts and start thinking in terms of what you want to achieve" (words and motions in vim-speak).
Your example of [C]hange [I]nner is a great one; that one in particular was life changing. Sure there are some words and motions that do require memorization, but so many others just flow naturally. And once you start thinking in actions, it's easy to see how they can layer on top of each other in really elegant ways.
I'm not even here trying to tout vim-like editors, I'd wager there are many editors that have some semblance of this kind of interaction, but rather to reiterate there's a shift from a PoV of function vs. goal.
Again, I don't think this is "the right way" but rather one of many perspectives that works in context with the phenomenology of me.
> It shows the creator comes from VSCode
Hey, one of the creators here, I actually daily drove Neovim for two years, before switching to Helix for a while, then finally Ki.
> multi-cursor is a useless feature
I was a Neovim macro user until I figured out how insane that was compared to multi-cursor after using Helix.
I still think their point about search and replace still stand though. I make most my edits with regex in neovim nowadays and I feel this is the superior paradigm: You don't even need to get to some specific location in order to edit it. I also almost only use search to move around the file and I can even reuse the searches for substitutions. It makes most vim motions and commands almost useless for me nowadays.
I also feel like macros are a more clunky and error prone way to do that substitutions can do. Almost never use them.
Yeah, macros are definitely helpful at times, but not as much as one might think.
I think the same goes for multi-cursor, though.
> I was a Neovim macro user until I figured out how insane that was compared to multi-cursor after using Helix.
Multi-cursor was the first plugin I installed when I moved from VSCode to Vim because I was used to hitting Ctrl+d to select all words and then replacing. Does Helix do something different?
1) First I reach for <C-v> for visual block selection if everything is neatly aligned.
2) Next choice is %s/search/replace(/c if I need confirm).
3) Macros, and I love it everytime I get to use them. I just record the movements, copy what I need to copy, paste it where I need to paste it, and it's repeatable for every line or block where the *formatting* matches. And this is the important part, the words don't matter. I still feel like a wizard using them.
As far as I understand multi-cursor option 3 is a no-go without macros if the words don't match. But macros don't care as long as the movements translate to the same edits. How does Helix multi-cursor work that make macros insane?
Sorry for derailing a bit, the search and replace using a query make sense for purly textual (non-syntactic) editing, but if you want to apply consistent syntactic modifications across multiple locations in the same file, you will need both multi-cursor and syntax node selection/navigation/modification.
It's hard to explain unless you actually try Ki, because it is a paradigm shift
I had an experience like this when I switched to a Keyboardio split keyboard. It was impossible to use at first. Then I do some deliberate practice with a typing tutor app and now I love it so much I own multiple.
Is there a good tutorial for some of these advanced text editing features?
In particular I’d like to get platform independent shortcuts / key bindings. I use both windows and MacOS daily, and it throws off my muscle memory for shortcuts like “go to beginning of line”
Have you seen any of the lisp tree editing modes for eMacs or vim?
Why not a vim plugin
We have one underway in https://codeberg.org/alicealysia/ki-bindings.nvim
> Note that the Ki keybindings cannot be simply implemented in Vim/Helix via key- remapping, due to the lack of the concept of Selection Mode, and implementing that requires major architectural changes in the core.