Consider kakoune/helix editing model

[matklad]

At the risk of starting a flame war, please consider focusing on kakoune’s object-verb model instead of vim’s verb-object :)

See https://kakoune.org/why-kakoune/why-kakoune.html for a an explanation of the idea.

Now, I don’t really have a stake in the game here, as I use neither vim nor kakoune regularly. However, I am fairly certain that kakoune model is superior, if we ignore “human backward comparability”, and I would say that a brand-new editor has a chance to do just that.

[Cody-Duncan]

I'd argue the model works better with multi-cursor editing, too. Multi-cursor editing is a foundational feature of what made SublimeText and vscode popular editors.

[dzhou121]

Am I right to think kak is kind of visual mode by default? Maybe we can support kak mode as a config as well.

Personally as vim user, if I need to copy or delete something, I always change to visual mode first, to have the visual confirmation that I’m doing the action on the right area. So I can see kak’s point. But at the same time, I don’t want a selection when I’m just navigating around so I still need a normal mode.

So a config to toggle between the two is a sensible way, just like we offered choice between modal and non modal.

[Cody-Duncan]

+1 for kak, vim, and non-modal toggle setting

[konsuko]

I have always struggled sticking with vim and recently landed on the Helix Editor, a brilliant project that's also written in Rust and has a fantastic vision: It's inspired by neovim and kakoune, though its modal editing paradigm is mostly based on kakoune (with some differences).

Would be great to have a future option to support helix-style editing in here as well.
The community is growing at a rapid pace and while I see myself using helix as my main editor, I'd really like to use Lapce as a VSCode replacement in the future without having to switch modal inputs.

So, +1 from me for adding multiple modal inputs: vim, helix and kakoune. Would be a killer feature!

[DakshG07]

Both Helix and Kakoune have great object-verb settings. I believe we don’t need both, and that sticking with Helix-style editing is better for the long run, as it’s documented pretty thoroughly(not to mention Helix is also written in Rust).

[wojpawlik]

Kakoune already has client-server architecture, Helix is moving in that direction: helix-editor/helix#39

[DakshG07]

Which is important!
Kind of like how VS Code has a Neovim extensions with embedded Neovim, you could have an embedded Kakoune.

This is much more effective than just emulating the layout.

[luccahuguet]

The future I envision is one where I can jump from helix to lapce and vice versa, both written in rust, similar workflow, and each with some advantages over the other.

For this to come true, a helix-like keybindings config/preset is needed, and even better as default!

[wsippel]

I've tried to get into VIM for years, but it never clicked with me. Learned about Helix a few days ago, tried it for a few minutes, and immediately made it my default editor on everything. Object -> verb seems just so much more sensible for an editor (to me, at least), and I also love the selection model. I believe Kakoune and Helix essentially work the same, and mostly differ in a few keybinds? If that's the case, having a Kakoune-like modal mode in Lapce (in terms of the selection model and command order), with the option to switch between Kakoune and Helix keymaps, seems like the perfect solution. I absolutely love Lapce's Code Lens for example, it feels so natural (amazing work there, by the way!), and that's just something you can't really do in a terminal based editor.

[hh9527]

I am big fan of helix, but I do think that the there should be a key-mapper-plugin to translate user input to any supported command. and by support vim/helix-mode by vim-mode.key-mapper.wasm and helix-mode.key-mapper.wasm.

Some mechanism to support any number of models defined by xxx.key-mapper.wasm may be a nessasary feature.

See what wezterm did in its keymap: https://wezfurlong.org/wezterm/config/key-tables.html

[DakshG07]

Even better, just expose a whole interface. This way, we can make it how we want. Also, an embedded Helix would be very nice.

[goyalyashpal]

my 2 cents:

rather than providing individual and particular clients, the better approach would be to provide support for their philosophies, and a default keybind, and providing option to put a custom keybind at will. so, smth like:

Current (for reference):

[goyalyashpal]

There are lines of distinction, and several points about some of those lines which are not discussed here.
But these can be crucial in prioritization, implementation and reproducing the same good experience in lapce:

line marked 1 (vi lineage, vs kak lineage):

• kakoune/helix are interactive, they have completion and description popups - both in code editing, as well as in command line, and other places.
  they'd needed to be linked to existing equivalent popups in lapce
• helix supports tree sitter based navigation
  This shouldn't be a major problem, as lapce uses tree-sitter, i'd assume it can be extended to textObjects and hence to selection and navigation too.
  i don't think n/vim has that. ain't sure about kakoune.

line marked 2 (kakoune vs helix):

• kakoune is NOT available on windows
• helix puts emphasis on more rememberable keymap, rather than minimizing keystrokes - which maybe more pleasant to many

---

Citations:

Code syntax highlighting using Tree-sitter, much faster and better than regex based highlighting.

... to give you code intelligence like code completion, diagnostics and code actions etc.

- Lapce
- lapce/lapce.github.io/-/index.html#L176-L178 (530d867)

Tree-sitter produces error tolerant and robust syntax trees, which enables better syntax highlighting, indent calculation and code navigation.

Navigate and select functions, classes, comments, etc and select syntax tree nodes instead of plain text.

- https://helix-editor.com
- helix-editor/website/-/templates/index.html#L22-L34 (f46aa54)

It's more important for the keymap to be consistent and easy to memorize than it is to save a key stroke or two when editing.
- helix-editor/helix/-/docs/vision.md#L19 (31f1455)

[JackMordaunt]

For what it's worth, lack of support for kakoune or helix style bindings is holding me back from truly using lapce - though I really want to! I just can't do vim. This project looks fantastic.

Maybe there's a bunch of potential users that are in the same boat as I.

[goyalyashpal]

my main concern is - how will lapce do the "interactivity" part of hx/kakoune - which is a key part in why we find these better than n/vi/m

[rosefromthedead]

I've been working on this, but not very quickly. If someone wants to take over then I can show what I have, otherwise I'll try to keep it going.

[eugenesvk]

See what wezterm did in its keymap: https://wezfurlong.org/wezterm/config/key-tables.html

this stack-based model of keybindings (where you can replace or just append previous "stacks" of keybinds based on various dynamic conditions) is awesome, wish more apps had this kind of flexibility. The main challenge there, though, is gettin lost in the stacks :), would be great if there were some tool that could dynamically show which key is mapped to which function defined in which stack

[eugenesvk]

But at the same time, I don’t want a selection when I’m just navigating around so I still need a normal mode.

That's also a (minor) annoyance I have with this model, though could this be solved via some smarter selection behavior: for example, you only get selection showing up after some delay in single-cursor navigation, so that just jumping around text would not show any selections until you've arrived at the destination?

[go2null]

love the direction this is going - helix/lapce is a much better combo than vim/gvim (command-line/gui)

[nyabinary]

Helix/Lapce! I 100% agree. Plus, more Helix-like features would be excellent, I decided to try Helix for a bit and my productivity skyrocketed, tbh lol, so I would love more helix features incorporated.

[panekj]

• which would allow it to be used directly inside other editors like lapce

this won't happen, multiple frontends/backends model works terribly and we are not interested in such implementation

[nyabinary]

Hopefully we can get some Helix/Lapce integration

[PotatoesFall]

@panekj what kind of implementation would be better? Taking some helix source code and adapting it to be built as part of lapce?

[SomeGuyNamedMay]

perhaps exposing stuff for keybindings in the lapce plugin system for defining model keybinding "schemes" as well as an easy way to switch between said "schemes" would work here?

[nyabinary]

Terminal model editing, maybe?

[goyalyashpal]

Terminal model editing

can u explain a bit more on that?

[knarkzel]

Terminal model editing

can u explain a bit more on that?

Should be possible to use modal editing in the terminal as well, not just the editor.

[goyalyashpal]

ohwkay. nice. but won't implementing it for terminal be a different beast altogether...
also considering the existing different modes (emacs, vs vi) in the bash shell atleast....

[nyabinary]

Any status on this?

[panekj]

Any status on this?

There would be a comment or issue status change if there was.

[j-dominguez9]

Is there something we can do in assisting with getting this feature? I want to use Lapce, but this is the only thing preventing me from doing so.

[MinusGix]

It is mostly limited by someone who wants to modify the cursor logic / etc. to have an extra setting to behave like kakoune/helix, and knows/can-learn how it should work.
The floem crate has the editor-core + editor, which has movement/cursor logic and other tidbits (though modal mode isn't hooked up for display as a default for the core editor view, the functionality is still there).