I think it is mostly crystallized, thus I'm happy to share it with you today.
Its main strength is first-class multi-cursor and structural (syntax) editing, which is a rare combination in the realm of editors (TUI or GUI alike).
Hope you'll enjoy it!
To summarize for those who know [Kakoune](https://github.com/mawww/kakoune) or [Helix](https://github.com/helix-editor/helix), the idea is that every command has the form ["selection mode" -> "movement" -> "action"](https://ki-editor.github.io/ki-editor/comparisons/modal-edit...) instead of Kakoune's movement->action.
So, instead of having separate commands for "next character", "next word", "next structural element", there is one command for "next" (as well as [a few additional motions](https://ki-editor.github.io/ki-editor/normal-mode/core-movem...)). Every command starts with a ["selection mode"](https://ki-editor.github.io/ki-editor/normal-mode/selection-...) like "column", "line", or "structural element".
It's hard to know without some practice and experience how much I'd enjoy it, but it is a good idea, and perhaps it'd be easier for a newcomer to learn than Kakoune/Helix.
[0]: https://github.com/nvim-treesitter/nvim-treesitter-textobjec... [0]: https://github.com/chrisgrieser/nvim-various-textobjs
In Ki, you only need to use `s` for any syntax node, while in nvim-treesitter-textobject, you need to use `vaf` for functions, `vac` for classes, and so on. Additionally, this also depends on how well the Tree-sitter queries are written, or if they're written at all.
However, once you get the hang of it you will find that most common operations can be achieved within 3 keypresses.
For example, to delete the current line, press `e` (Line selection mode) and then `d` (Delete).
To delete the current word, press `w` (Word selection mode) and then `d`.
To insert new text at the end of the current line, press `e`, then `a` (enter insert mode at the end of the selection).
To insert new text at the beginning of the current line, press `e`, then `i` (enter insert mode at the beginning of selection).
To go to the first line, press `e`, then `,` (Move to the first selection).
To go to the last line, press `e`, then `.` (Move to the last selection).
There are too many of such examples that I cannot fit in one comment, but I think you get the idea. It's all about creative combinations between selection modes and movements.
- dd
- diw
- A
- I
- 1G
- G
Code golfing, I count 12 keystrokes in your example, and 10 in stock Vim.
This is the problem which kak/helix/Ki have with drawing in experienced Vim users: a language is a language, once you know it, you know it, and switching is mostly a drag. It does seem like the "it's better to do it this way" pitch works well enough for those who haven't used a modal editor and are curious.
I disagree with the premise (from the Fine Article) that vi/vim is in some way less coherent as a language. Languages don't really do 'coherent', they do 'expressive'. To get expressive, you need some complexity, and all you can do is hide it in different places.
The argument for Vim's coherence can be found here: https://stackoverflow.com/questions/1218390/what-is-your-mos...
The basic premise of Kakoune, which Ki seems to share, is that it's more natural to move first and then command. That's not how my brain works: I know what I want to do immediately, and it takes more time to express the region I want to do it to (simple things like a line or lines are instant, but would be either way). If I found the opposite more natural, I would use `v` more heavily than I do, and then I might wish to switch. The variety of human minds and personalities virtually guarantees that different people will find one or the other to be more natural.
That all said, I think structural editing is a fine thing, and encourage any and all experiments in modal editing: vim is just a language, not a law of nature, and totalizing attitudes towards language smack of cultural imperialism. Perhaps Vim is stuck in a local optimum, although I don't happen to think so.
So, personally, I might try a structural editor which speaks fluent Vim, but won't otherwise. It's like Dvorak: I see the point in the abstract, but I type around 100WPM without any RSI, I know that switching will make me slower, potentially for a long time, and I'm pessimistic that the final state would be faster: the world record holders use QWERTY.
So I'll just limp along with treesitter objects extensions and hope for the best.
the asciinema demos are super cool! btw asciinema has an option to record input keystrokes as well as screen output, but i don't know if there's a way to display them in the standard js web player for it
Thus, Vis is easier to learn than Helix/Kakoune and gives you (IMO) the most useful feature of Helix/Kakoune.
Unfortunately, Vis is also a bit bare-bones, I don't think it has LSP support for instance.
https://gitlab.com/muhq/vis-lspc
https://github.com/fischerling/vis-lspc
I've linked both because it seems like the github repo has a pull-request with a bunch of updates but the gitlab repo seems to be more up to date?
I've not tried getting it working yet, but I've seen people on Reddit (or lobste.rs, I don't remember) saying they got it working.
About the editor : I love what I see. I must admit that for me now the ultimate vim-fu I settled upon for navigating/editing is searching/replacing ( with something like traces.vim and `set incsearch on` so it feels nicer ) so this new paradigm makes a lot sense I believe.
Although i have some questions / concerns: - "Command mode" (`:`) seems a bit more different compared to Helix / Kakoune and maybe even VIM. I would have also expected to be able to change the theme like so.
- I couldn't find (after just a bit of skimming around the docs) how to adjust the sizes of e.g. the file-tree. Or well, even change to a different window. I like the concept of having multiple windows within the browser, but couldn't really figure it out.
Also, layouts may be a neat idea to implement, so that e.g. the file browser will always spawn on the exact same location of a defined layout (may as well be pre-defined) - Theme browsing is a little bit slow i feel like, not big of a deal, just something i noticed.
- The docs may also need a way to change from selection based movement (e.g. via Token / ts node) back to character based.
- The gui may need some improvements, maybe it's just subjective perception, but having a small window with all the options there is good, but i couldn't intuitively tell whether or not those were all the options (e.g. in <SPC> mode). Also i am fairly certain there were more options.
- A builtin tutor is also a neat idea, considering that your editor looks very young, i am sure you thought of that, but it's a really easy way to get new users comfortable with using it.
Anyway, very neat project! I will keep an eye out and eventually try and daily it, at least for a week. The structured editing you implemented is REALLY GREAT, like better than i could have done it (or even thought about).
For character-based movement, simply press 'z' to enter the column mode.
Regarding the built-in tutor, yes I really have to put in the effort, because it's so much harder than authoring documentation.
And yes, a lot more has to be improved, Ki needs a lot of polishing around the edges.
I did eventually find this in the documentation, under the "regexp selections" section. I think it should be more prominently displayed in other sections, since it's a natural thing to want (at first).
I am enjoying the editor (as a current helix user), and looking forward to trying it more.
As is, Dance with Kakoune bindings is good enough and supports all of VS Code plugins, so I'm not sure I'll get enough use of Ki to actually get used to its bindings. Or maybe I'll play with it anyway...
P.S. I linked this in [Dance's forum](https://github.com/71/dance/discussions/347), perhaps it'll turn into an actual discussion.
For the configuration I'm planning something crazier, I might use my programming language that I built earlier (https://github.com/wongjiahau/kk).
Here's a short video demo if anyone is interested: https://youtu.be/owuuFxDBQh4
Case agnostic search and replace is such a nice feature too. I have no idea why it isn't standard in IDEs.
It was a bit hard to see on mobile - what are the hotkeys in the first demo to select the full function call?
I’m building my own semi-structured editor but it’s specifically for UI design. Love seeing more examples for inspiration!
Good keybinds though, I like it a lot.
going to try this out: the idea of breaking motion -> action into something like topic -> adjective -> action has been kicking around in my head for a while
Aside from that congrats!
Also, most importantly, syntactical selection/navigation/modification is first class, although it is somehow supported in Helix, the default keybindings are not very accessible.
Another big difference from Helix is its internal architecture, most Helix components were rebuilt from scratch, while in Ki every components uses the core editor as the base, which means all components shares the same set of keybindings, you don't need to learn different set of keybindings for different components.
Over the years, I've heard many arguments against Emacs but found none of them convincing, especially if you take the point of view that learning a powerful tool can be an essential asset in any profession. Emacs certainly is such a tool.
The same question could be asked about vi(m), although that one at least received some hipster love in recent years. That seems to have cooled down somewhat too, though.
I've set it (emacs 29.4) up like that (LSP mode (including rust), DAP mode, 160 emacs packages, daemon mode) and it works very fast for me. It can do project tree, intellisense, refactoring, macro-expansion and auto-implementation that way.
Opening a new document takes about 75ms for me.
Modern emacs has native compilation via gccjit.
package specification: https://github.com/daym/guix-config/
emacs config: https://github.com/daym/emacs-config/
My problem has always been that I prefer to use styluses, and to hand-write things out at times and to use a stylus for editing/annotation and to have a graphical environment for displaying markup and so forth (which reminds me, I need to see how the new LyX 2.4 works w/ a stylus).
From the outside Emacs never drew me in. It didn't do anything "bad", but the premise behind vim (motion actions, etc) just sounded logical, like building blocks , and as a result drew me in for being easier to understand the basics of.
I could never grasp what Emacs even "was", as a pre-vim beginner. To this day i still don't know, but my general assumption is it's more built around commands rather than little primitives like Vim does. Which, seems fine - just never was enough to hook me.
These days i'm mulling on my own editor and i should probably better understand Emacs. I've watched some guides on Org Mode, which is a big area of focus for me, but even that just seems like Markdown with an LSP (link jumping/etc), so i still must be missing something heh.
For me, the concept of modal editing has never been appealing, so even though I know some basic vi, I never got into it. Perhaps I was influenced to some degree from taking some HMI classes in college (see Larry Tesler), I don't know.
Emacs is really just an editor, but it was built from the get-go to be super-hackable and has a very solid modular architecture, based on well thought-out concepts. That allows it to offer specialized functionality for different file types in the form of add-ons ("modes"), and it allows every end-user to fine-tune the editor to their own liking.
If you want to get a grasp of its capabilities, check out the "Emacs rocks!" series [0] - it's a bunch of short videos demonstrating some interesting things you can do with Emacs.
(I'm not trying to convert you, I'm just trying to get across what Emacs is)
Emacs exposes lots of rich functionality to the user.
Almost every part of your comment is wrong, too, so that certainly cannot be the reason.
