Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ki Editor - an editor that operates on the AST

ki-editor.org

Post reply on HN
Print view View original

41–50 of 154 posts

Re: Ki Editor - an editor that operates on the AST

#41

Post by exidex »

muixoozie wrote: post #34

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.

It's a shame that editors are build around the editing model, so much time has been wasted by recreating everything. Neovim is a perfect editor in many aspects but editing model is not one of them, in my opinion. Helix or even Ki would not be needed if Neovim allowed to completely replace the vim part of it with plugins

Re: Ki Editor - an editor that operates on the AST

#42

Post by freedomben »

sigbottle wrote: post #38

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…

I feel the same way. Learning Elixir and getting into macro writing was really helpful for me. Lisp is also the same way though for me the syntax of Elixir resonated a lot better for me. Many paths to the destination and all that, but figured I'd share in case it's helpful to someone

Re: Ki Editor - an editor that operates on the AST

#43

Post by hou32hou »

sigbottle wrote: post #38

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…

TBH, it's actually not as hard as you think, most of the time, what I do is just select the whole syntax node and delete it, copy it, or replace it, and only 20% of the time would actually require deliberate understanding of how the AST is structured in the current language I'm coding in.

Re: Ki Editor - an editor that operates on the AST

#44

Post by wizzwizz4 »

exidex wrote: post #41
muixoozie wrote: post #34

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.

It's a shame that editors are build around the editing model, so much time has been wasted by recreating everything. Neovim is a perfect editor in many aspects but editing model is not one of them, in my opinion. Helix or even Ki would not be needed if Neovim allowed to completely replace the vim part of it with plugins

Can you elaborate on how this might look, both from an abstract perspective, and (if you've thought about it) from an API perspective?

Re: Ki Editor - an editor that operates on the AST

#46

Post by chamomeal »

scriptsmith wrote: post #7

The "First-class syntactic selection" reminds me of my most used shortcut(s) in Jetbrains IDEs: the Expand / Shrink Selection. Ctrl + W Ctrl + Shift + W 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.

I use it constantly in helix too. The vscode one is meh. I think I saw a discussion in github once about switching to tree-sitter, which would improve AST-related actions. I don't think it went anywhere though.

I love AST aware editing. I think it's one reason it's always been so nice to edit lisps. Stuff that is complicated to describe in javascript (and doesn't have LSP support) p much requires a whole AST parser, but in lisp it's just a simple list operation. When I go back typescript after a weekend of clojure, I reeaally miss slurp! and other paredit commands

Re: Ki Editor - an editor that operates on the AST

#48

Post by exidex »

wizzwizz4 wrote: post #44
exidex wrote: post #41

Earlier quoted context omitted.

It's a shame that editors are build around the editing model, so much time has been wasted by recreating everything. Neovim is a perfect editor in many aspects but editing model is not one of them, in my opinion. Helix or even Ki would not be needed if Neovim allowed to completely replace the vim part of it with plugins

Can you elaborate on how this might look, both from an abstract perspective, and (if you've thought about it) from an API perspective?

I didn't really spent time thinking about it, because from reading their issue tracker, I very much doubt neovim would consider something like that. Partially because of how much of it is already vim specific and it would be very difficult to abstract that away, but mostly because of ideology.

You can already to a lot in Neovim with plugins, including recreating Helix, Ki, whatever. But the problem is that the vim state machine is always present underneath it, resulting in unwanted behaviors or impossibility to implement some things. I would envision it to pretty much allow to listen on raw keyboard and mouse events. However cursed it sounds, it should be possible to fully implement vscode or any other editing model in neovim

Re: Ki Editor - an editor that operates on the AST

#50

Post by wizzwizz4 »

exidex wrote: post #48
wizzwizz4 wrote: post #44

Earlier quoted context omitted.

Can you elaborate on how this might look, both from an abstract perspective, and (if you've thought about it) from an API perspective?

I didn't really spent time thinking about it, because from reading their issue tracker, I very much doubt neovim would consider something like that. Partially because of how much of it is already vim specific and it would be very difficult to abstract that away, but mostly because of ideology. You can already to a lot in Neovim with plugins, including recreating Helix, Ki, whatever. But the problem is that the vim st…

I'm not sure how that's not "recreating everything". What's still shared if you replace the whole state machine (handling file management, etc) and also replace the whole input handling system? A terminal emulator and a copy of Lua?
Post reply on HN