onivim / oni2

Native, lightweight modal code editor
https://v2.onivim.io
MIT License
7.76k stars 274 forks source link

[Feature] Kakoune mode #790

Open glennsl opened 4 years ago

glennsl commented 4 years ago

Kakoune is a modal text editor, like VIM, but absolutely superior! (In my humble opinion, of course)

What?

The gist of the difference between VIM and Kakoune is that, while VIM commands generally have a verb-object shape, Kakoune commands have an object-verb shape.

For example, in VIM, dw first says something should be deleted (d), and then that this something is the remainder of the word under the cursor (w). The Kakoune command is the opposite, wd, which first specifies that the the rest of the word should be selected (w), and then to delete this selection (d).

I propose that this "style" of command input be made possible as an alternative to "VIM mode".

Why?

The benefits to this approach are:

  1. Selection commands compose, actions don't. For example, wwd will delete the next word. (wWd, or 2Wd, will delete the rest of the current word AND the next word).

  2. It removes the need for a separate visual mode.

  3. It provides immediate visual feedback by showing the selection on-screen. VIM on the other hand requires you to keep a model of the "selection" in your head. For example, to delete the next 9 words, in VIM you can use 9dw, but you have to count the words in advance. Or undo the action and try again if you miss. In Kakoune you can ballpark it, observe the selection and correct it if it's off before doing any editing action. For example, select the next 10 words (10W), correct it by unselecting the last (B), then delete the selection (d).

  4. With additional support for multiple selections, the combination of immediate visual feedback and composition means you can do some very elaborate selections without planning the entire thing out in your head in advance.

Read more, and watch fancy animated illustrations, at Why Kakoune?

How?

From what I understand of the code base so far (which admittedly isn't much) it seems like the least intrusive approach would be to provide a replacement for libvim (or reason-libvim). This means reimplementing a lot of stuff like buffer management, commands, and... yeah, a lot.

Perhaps it would be possible to wrap libvim in some way and delegate most of it right back to libvim? Or emulate it on top of libvim using existing commands?

The cleanest approach might be to pull the keymapping part of libvim out. This would undoubtedly complicate the currently very minimal libvim API, and is fairly intrusive, but might still be less work than the other options. I also think this is a better option long-term, as control over keymapping adds flexibility that I think will be desired for other features (such as contextual command help, also a feature of Kakoune).

yunti commented 4 years ago

I hadn't heard of Kakoune until you mentioned it recently on discord. I'm pretty fascinated by it now.
I think having a libkakoune might be too onerous a task, particular at this stage of the project, but perhaps a translation layer between keyboard output from sdl2 (when finalised) and libvim might work. I think that would work for the object-verb part of kakoune, but instead of a direct translation to vim of verb-object it would need to be changed into visual mode to get the visual feedback of the selection. So something like 3wd would be translated to v3ed. (not sure what the equivalent of x in kakoune is though, so some edge cases to think about).

I'm not sure how things like multiple selections in kakoune would work though? Might need to test on some example to get some ideas how to generalise.

Alternatively as bryphe nearly put neovim as the core of onivim then perhaps specing out an api for an buffer engine might be a good idea and trying to get kakoune to work with this.

glennsl commented 4 years ago

Thanks for the input @yunti!

I think having a libkakoune might be too onerous a task, particular at this stage of the project

It might have to be a long term project, with libvim being split into separate pieces over time perhaps. I think that's be good for the project as a whole anyway.

...instead of a direct translation to vim of verb-object it would need to be changed into visual mode to get the visual feedback of the selection. So something like 3wd would be translated to v3ed.

Yeah, that's the kind of approach I was considering as well, but I think it'd get really messy. You can't exit visual mode without losing the selection, not through normal commands at least, so it seems you'd have to keep track of which selection operations have been performed, to be replayed later if the user enters a command that requires going back to normal mode.

not sure what the equivalent of x in kakoune is though, so some edge cases to think about

It's just d. The character under the cursor is considered the selection, so it's the same command as with any other selection.

x instead selects the current line, since there's no special-cased dd commands and such. xx selects the next line and xX selects the current AND next line, just like with w, ww, and wW. It's a very consistent and easy to learn command scheme (dd does have the benefit of being a tiny bit faster than xd however).

I'm not sure how things like multiple selections in kakoune would work though?

You'd usually get multiple selections by doing a search that finds multiple matches. Subsequent commands are then just applied to each selection individually. I imagine it would work much the same way with vim.

...specing out an api for an buffer engine might be a good idea and trying to get kakoune to work with this.

Absolutely. I don't know much about the internals of libvim, but I'm hoping it already has a separate internal API for a kind of "buffer engine" that could be exposed, so that the input handling part could be extracted relatively easily. If not, then adopting an editor back-end like Xi might be a better approach, since I believe that's pretty much what it does. But, again, that would be a long-term project. Like Oni3, I would guess.

bensleveritt commented 4 years ago

Just to add that VS Code has some basic kakoune extensions, would an extension work in this case? Given that the core wasn't designed for different editors, it sounds like it'd be a lot of work to retrofit it in.

I would love for this project to support kakoune's interaction model (as I've moved over from vim, but can't quite stop using VS Code).

lessless commented 3 years ago

This concept sounds much more pleasible

samholmes commented 2 years ago

+1