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

121–130 of 154 posts

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

#121

Post by cyberax »

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.

JetBrains also experimented with AST-based editing: https://www.jetbrains.com/help/mps/fast-track-to-mps.html#st...

An overview video: https://www.youtube.com/watch?v=XGm_khXZl44

I tried it, but it just was too clumsy. Sometimes refactoring/editing needs to go through phases where the AST is invalid, and MPS makes that just too clumsy.

But with AI this might be a different story.

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

#123

Post by layer8 »

lkjdsklf wrote: post #92
layer8 wrote: post #51

Earlier quoted context omitted.

Yes, Java IDEs have had these since sometime in the 2000s.

It’s still some time in the 2000s and will be for the next 974 years

Not according to common usage: https://en.wikipedia.org/wiki/2000s

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

#124

Post by wtetzner »

__MatrixMan__ wrote: post #119

I think the challenge with AST editing is discoverability. Like, I know what I want to select, I can see it there on the screen, but I don't know its name. I've been dreaming of writing a plugin that surrounded the cursor in differently colored scopes. So instead of "next function" I'd be thinking "next blue" (blue being the color that functions are currently painted in).

I think there's still value in generic AST-level operations. Like expand selection and shrink selection. Or select around the current node vs select inside (whatever that means for the current node type).

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

#125

Post by aleksiy123 »

radford-neal wrote: post #83

Many years ago, I created an editor operating on syntax trees that I think is more "hard-core" than this - that is, only tree-oriented operations are done. There is no parsing of text, since entering plain text, rather than a tree, is impossible. Hence, there can be no syntactically invalid programs. The challenge is getting this to be a useable way of entering programs. I think I made progress on this, but the feasi…

I actually used a language and editor like this in a previous large company.

It was an experimental language that they wanted to replace their current application level language and was built ontop of JetBrains MPS https://www.jetbrains.com/mps/ which has that feature among others.

My personal opinion after working with that lang is all of this is that its theoretically interesting. But a dead end in practice along with visual coding etc.

The universality, simplicity, and legibility of text as interface for both humans and machines is too hard to beat. I think LLMs is just the most recent example of this.

Things that don't work in practice:

- You need a special editor, its heavy and slow, you lose all the ecosystem around them.

- You can't just cat or inspect the raw file, you can't see it in terminal at all.

- You need a new version control system, review system, and people need to learn it.

- You can't use any existing tools for working with code, you are essentially starting from scratch, and lose all the benefits of all the work everyone else is doing around tooling, dev saas etc.

- humans don't think in trees, they don't think in syntactically correct programs. Its actually absurdly frustrating writing a program in only syntactically correct edits. 99% of the time you are coding, your work is probably syntactically and semantically incorrect.

The tooling that is able to either make the right tradeoff around strictness or allow the users to make the that tradeoff is what ends up being used in practice. A good example of this typescript with gradual typing, python with type annotations, etc.

I think these editors just fall in a bit too far right on the strictness scale.

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

#126

Post by scotty79 »

Normal_gaussian wrote: post #84
radford-neal wrote: post #83

Many years ago, I created an editor operating on syntax trees that I think is more "hard-core" than this - that is, only tree-oriented operations are done. There is no parsing of text, since entering plain text, rather than a tree, is impossible. Hence, there can be no syntactically invalid programs. The challenge is getting this to be a useable way of entering programs. I think I made progress on this, but the feasi…

> The challenge is getting this to be a useable way of entering programs. Well exactly. When the path between Program A and Program B can only be valid programs, you are going to end up with either a much longer, less intuitive path, or deleting everything and starting again. It can also be quite possible to invent structures which are valid but have no valid path to creating them.

One idea would be for it to work like code completion. Once you start writing a structure the rest is auto-suggested so it does not break the tree.

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

#127

Post by hou32hou »

__MatrixMan__ wrote: post #119

I think the challenge with AST editing is discoverability. Like, I know what I want to select, I can see it there on the screen, but I don't know its name. I've been dreaming of writing a plugin that surrounded the cursor in differently colored scopes. So instead of "next function" I'd be thinking "next blue" (blue being the color that functions are currently painted in).

In Ki you don't have to know the name of the syntax node, you can just press `d m`, and the editor will show the labels of all the syntax node visible that you can jump to.

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

#128

Post by hou32hou »

SloopJon wrote: post #56
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.

An editor that tries to be layout agnostic is almost certainly going to be a nightmare for people like me who set the layout in the keyboard itself. I downloaded the editor (I'm on Windows at the moment), and tried it with my keyboard set to Dvorak, which was plainly broken. I'm sure there's a way to fix the mapping, but when software thinks it's smarter than you, you end up feeling pretty dumb.

Have you used `*` to pick the keyboard layout?

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

#129

Post by tzot »

joquarky wrote: post #116
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.

One problem is I got so used to Ctrl-W that I use it in other applications and usually wind up inadvertently closing the tab.

I had this issue too, so I remapped Ctrl-W/Shift-Ctrl-W to Ctrl-\/Shift-Ctrl-\ . (Also git operations became two-key sequences, starting with Ctrl-G and that damn Ctrl-K stopped being the shortcut for commit.)

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

#130

Post by radford-neal »

aleksiy123 wrote: post #125
radford-neal wrote: post #83

Many years ago, I created an editor operating on syntax trees that I think is more "hard-core" than this - that is, only tree-oriented operations are done. There is no parsing of text, since entering plain text, rather than a tree, is impossible. Hence, there can be no syntactically invalid programs. The challenge is getting this to be a useable way of entering programs. I think I made progress on this, but the feasi…

I actually used a language and editor like this in a previous large company. It was an experimental language that they wanted to replace their current application level language and was built ontop of JetBrains MPS https://www.jetbrains.com/mps/ which has that feature among others. My personal opinion after working with that lang is all of this is that its theoretically interesting. But a dead end in practice along w…

These are good points, but are mostly pragmatic, resulting from the rest of the system not being designed around a tree representation. Of course, that can be decisive in practice...

A more fundamental issue (which I mention in the document) is that there is a discordance between the 2D textual display and the underlying tree. I think this becomes more apparent when input is not only keystrokes, but also mouse positioning.

Of course, these disadvantages do not necessarily outweigh the advantages of editing in terms of trees!

Post reply on HN