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

81–90 of 154 posts

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

#81

Post by the__alchemist »

leoc wrote: post #76
the__alchemist wrote: post #69

Earlier quoted context omitted.

Hero! I had not done my homework/have not been aware, but these all look fantastic! The stacked clipboard is something I periodically mentally complain about (Why is clipboard on every OS/tool I've used single item?) I will add one that are possibly more well-known: - ctrl + shift + F: Find text in any file - ctrl + N: Find types (structs, classes etc) - ctrl + shift + N: Find any file by name or path

Windows has had a pretty usable stacking clipboard for a while! You just have to activate it. Since you can pin thing into it it’s also quite useful as a rough and ready way to type special characters you use frequently.

Wow. Looks to not even be a PowerToys feature. Win + V

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

#82

Post by wizzwizz4 »

exidex wrote: post #53
wizzwizz4 wrote: post #50

Earlier quoted context omitted.

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?

There are certainly different possibilities of where the line would be drawn. I am not that familiar with vim internals, but I don't consider file management to be part of vim editing model. And we are only talking about editing model (e.g. b being beginning of a word), not the whole editor (plugin system, ui, lsp and treesitter integration, etc). Though it is true that some parts are more tightly related to "vim". T…

But doesn't the ecosystem around the editor depend on the editor being, at its core, Vim? https://neovim.io/doc/user/lua-guide/#lua-guide-api describes "three different layers": basic examples like https://neovim.io/doc/user/lua/#watch-file call into the Nvim layer.

I think the idea's good, but I don't think you could modify Neovim to support it while retaining the ecosystem – not without also modifying much of the ecosystem, at which point it may be easier to do a straight port to a different editor, or construct a compatibility layer (essentially reimplementing enough of Neovim in the new editor that the ecosystem still works).

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

#83

Post by radford-neal »

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 feasibility varies with the programming language.

I can't run it any more, since the display hardware it assumed is no longer available, but you can read about it at https://ucalgary.scholaris.ca/items/da8b823b-c344-4ffb-aa37-...

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

#84

Post by Normal_gaussian »

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.

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

#85

Post by exidex »

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…

Pantograph[0] seems to be a more recent attempt to implement the same idea. It is still not a general editor but generalizing it to ranges of tree selections looks promising

[0]: https://pantographeditor.github.io/Pantograph/

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

#86

Post by exidex »

wizzwizz4 wrote: post #82
exidex wrote: post #53

Earlier quoted context omitted.

There are certainly different possibilities of where the line would be drawn. I am not that familiar with vim internals, but I don't consider file management to be part of vim editing model. And we are only talking about editing model (e.g. b being beginning of a word), not the whole editor (plugin system, ui, lsp and treesitter integration, etc). Though it is true that some parts are more tightly related to "vim". T…

But doesn't the ecosystem around the editor depend on the editor being, at its core, Vim? https://neovim.io/doc/user/lua-guide/#lua-guide-api describes "three different layers": basic examples like https://neovim.io/doc/user/lua/#watch-file call into the Nvim layer. I think the idea's good, but I don't think you could modify Neovim to support it while retaining the ecosystem – not without also modifying much of the e…

Add that to a long list of side projects I would like to do "at some point"

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

#87

Post by gritzko »

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 work on AST based revision control. I have a stack of ideas on how to achieve the same Ctrl+W effect with commits/diffs/cherry-picks. All still in flux. If you have some thoughts to share, please do.

[1]: https://github.com/gritzko/librdx/tree/master/be#readme

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

#89

Post by jillesvangurp »

kfse wrote: post #77

How does this work in the many cases where in-progress edits result in an unparseable structure?

You just complete to a parsable structure.

This stuff reminds me of intentional programming (Charles Simonyi). That never really panned out but the premise with intentional programming was that programming is about AST transformations that are correct (sort of like refactoring) but all the way down to the machine code level. You get these increasingly more complex languages that are defined in terms of building blocks that are ASTs.

Refactoring of course is based on the same notion that manipulating code correctly at the AST level is a lot easier than messing around with text files. That came out of the smalltalk world originally which also had very fancy IDEs already in the nineties where everything (including the IDE) was something you could mess with. Refactorings were defined as syntactically correct transformation of one AST into another (rename, extract class, move function to parent class, etc.).

Charles Simony had a solution for what you describe as well. Just serialize stuff to text if somebody wants to "edit" and then parse it back when they are done. What happens to the text in between of course is the programmer's problem.

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

#90

Post by skydhash »

School-Cotton wrote: post #70
skydhash wrote: post #5

Earlier quoted context omitted.

Vim is Emacs applied to Vi

Not even close.

How is it not?

Scripting language? Check!

Custom commands? Check!

Windows management? Check!

Build tools integration and error-based navigation? Check!

File manager? Check!

Post reply on HN