"Post-Vim" modal editing... mode

[Daeraxa]

Sorry if this is a bit of a rambling type of post but I had some thoughts and wanted to see if I'm alone in this.

So I've been having a play with vim mode in Zed and whilst I know it is under active development and is at least somewhat functional, it did make me think about 'vim mode' in general.

I've used Vim a fair amount in the past and I think what makes it great is really the flexibility and extensibility but honestly, whilst I love the modal editing paradigm, I've never really got to grips with vim shortcuts. They obviously work just fine but many of them are particularly clunky or unintuitive. For this reason I've found myself using Helix (https://helix-editor.com/) an awful lot recently and I just find it so much more natural to use, mostly due to the change in the selection -> operation order and more obvious shortcuts (yes I know Kakoune is very similar in this sense but I've never really used it).

What I'm trying to get at is that I would love to see a graphical editor such as Zed actually have a fully integrated modal editor that isn't just tacking on some vim shortcuts, rather it would be something that works and makes sense in the context of the entire application. This isn't a dig at the current vim mode in Zed, I realise it is in active development and I've not even used the current implementation that much to really have an opinion on it, this is more of a general thought. Ideally the level of integration would extend to other features inherent to Zed and its UI as well as being available in the rest of the application (e.g. being able to navigate outline mode or the command palette in a modal way as well as having dedicated "vim-like" bindings to enter modes to navigate and use things provided by the LSP or tree-sitter.

Obviously the benefit of the vim way of doing things is that it is far more well known but I'm not sure that should be a reason in itself to stay with it forever, particularly if some kind of compatibility for vim style could be put over the top of it ('it' being this hypothetical modal editor... mode).

Now this might all be nonsense in which case I'm happy for people to inform me why I'm wrong or provide a different point of view but I'd be interested to see if anyone else has any comments on the topic. Basically I love the idea of having the power of modal editing but without having to bring the baggage of the past or trying to make a round peg fit a square hole.

[ijzerbroot]

I am also of the opinion that helix is way more intuitive than vim but I'm the kind of person who would use vim primarily in insert or visual mode so this is probably a minority opinion.
FWIW: I have personally never felt the love for normal mode (it doesn't switch itself off when I'm done with a command so I always have to expend mental energy to keep track of the active mode). Vim's main attraction for me has always been the fact that one can give commands using normal letters rather than awkward command/control+key reaches or heaven-forbid mousing.
This of course coupled with basic composability ("Change Around Quote"). Vim has no need to remember a million shortcuts.
For my money using an easy-reach "prefix", followed by a "command"(-combo) seems nice (kind of like vim's ctrl-o but that is not very well implemented as it generally does not work for commands that take you to normal mode when they finish)
Vim's commands are sometimes historic; nobody calls copying "yanking" anymore and no modern editor should, either.

TL;DR
Modal editing has never felt natural to me but being able to "command" the editor in simple language, using quick and easy-reach keyboard-keys (not being "command-foo", "ctrl+shift+bar") is a beautiful thing indeed. Stackable commands (i.e.: macro's ?) within easy reach make sense to me. Like: prefix - selectioncmd -> action1 -> action2 -> enter to confirm and end the command mode

[thiagomajesk]

Yes! Yes! Yes! I do share your opinion on this...
I've never managed to incorporate Vim into my workflow because of the same constraints.
What makes me like Vim-style, more so the editing that Helix brings to the table is two things:

1. Having mnemonic shortcuts that are easy to remember and combine
2. Having commands that allow for complex operations on text, which is a superpower.

I'd love to have something like a "Power Mode" or "Command Mode" in an editor without having to inherit all of Vim's philosophies like using hjkl or y for yanking and other exoteric choices from past limitations. What @hovsater said down in this thread makes a lot of sense to support something like this.

[nathansobo]

Hey there. I think on a longer timeframe, I'd love to explore a more thorough rethinking of the modal editing paradigm, and ideally make Zed's binding system and existing "vim mode" powerful enough to express other patterns.

While we're the new kids on the block, however, it's super important that we can make users from existing editors feel comfortable when they first try Zed. It's hard work to switch editors. I think once we get more users, it would be really fun to explore new approaches that somebody who is already committed to Zed can explore trying when they're in a position to develop new muscle memory.

Love these kinds of discussions. Let's push things forward. Just wanted to explain our thinking in the short term. Thank you!

[Daeraxa]

I agree, onboarding is far more critical at this stage, I very much mean this as a "looking to the future" type discussion (hence why it is posted here and not as an enhancement or anything like that).

I actually think Zed is in a very interesting position where it has the opportunity to grab people who probably aren't as invested in their current way of doing things. Heavy and long time Vim users aren't about to migrate away from Vim and likewise with ardent VSCode users who almost seem to have developed it into a third entry into the text editor wars.

Modal editing has always had a very steep learning curve but I think a GUI app like Zed is in a very good place to reduce that curve (rather convieniently Neovide comes to mind here... can't possibly think why 😄) by holding the users hand as much as possible whilst still providing all the tools needed, not constrained by the limitations of a terminal.

For me, although I like modal editing, I see myself using Zed almost entirely in "non-vim" mode simply because I've got very much used to the Helix style and struggle to go between the two for anything more complex than the basics (it is less about the actual keys and more about the selection <-> operation order thing that requires a bit more mental processing).
I the short term I expect that I will just use the two in tandem (especially seeing as it will be very easy just to open a terminal app within Zed).

[hovsater]

I'm late to the party but I wanted to share some thoughts on a concept I call "stackable keymaps" which I'm using for my own editor, kle. This concept was originally taken from mle. The premise is really simple. Keymaps work like a stack. You can push new keymaps onto the stack, and you can pop keymaps from the stack. Keymaps may optionally fallthrough (e.g., a key binding not found in the current keymap will fallthrough the keymap below it). Key bindings may specify what keymap they belong to (if no keymap is specified they belong to the default keymap).

This allow you to support all kinds of different use cases. By default, Zed would ship with a default keymap out of the box. Basically what we have now. Vim mode would be implemented by changing the default keymap. The beauty in this architecture is that you get modal editing for free. The default keymap for "Vim mode" would be vim_normal. Pressing i would push a new keymap onto the stack, vim_insert. Pressing escape would pop the current keymap from the stack, leaving you in vim_normal again. It's also very flexible as you can push/pop keymaps as you please.

I proposed the same concept to Craig (the author of dte) here. There I also go over some mle specific concepts in greater detail.

[Arazu161]

Keymaps work like a stack. You can push new keymaps onto the stack, and you can pop keymaps from the stack. Keymaps may optionally fallthrough (e.g., a key binding not found in the current keymap will fallthrough the keymap below it). Key bindings may specify what keymap they belong to (if no keymap is specified they belong to the default keymap).

This sounds quite similar to how keymaps are defined in the open source keyboard firmware ZMK. Keymaps are written in "layers", with the possibility of "transparent" keys, which fall back to the first definition in a lower layer. For example, on an existing keyboard "1" is on layer 0 and "!" is on layer 1, and holding the shift key moves you from layer 0 to layer 1

Regarding modal editing, there is an extension for VSCode simple called "modal edit". Instead of emulating a particular editor, this extension exposes a way to combine any keypress, or sequence, with particular commands allowing you to effectively write your own modal editing experience (iirc it comes with a vim preset). I think this is a superior approach as, in the context of VSCode, it provides a much more native experience as it makes use of existing features, rather that trying to emulate vim features

[nathansobo]

Stackable keymaps sounds interesting. Curious how you see them being used beyond emulating the vim behavior.

[hovsater]

@nathansobo great question. In kle, I've used them pretty extensively. For instance, pressing C-f enters search mode and pushes a new keymap kle_search onto the stack. Now I can press c to toggle case sensitivity and C-c to leave the search altogether.

Pressing M-x enters command line mode and pushes the kle_command keymap onto the stack. It provides readline bindings for moving within the single line prompt.

I could see this be applied equally to Zed. Where opening find/replace as an example, would push a new keymap onto the stack.

[ijzerbroot]

This sounds very appealing; compared to vim's modes (which have always felt more like "sticky states" to me) your examples sound quite intuitive as the stacks are context-dependent? This feels a bit like an analogue to traversing a context-sensitive virtual menu-like structure where visual cues for logical next choices might be possible, aiding discoverability.

[thiagomajesk]

@nathansobo I don't know if this helps, but I've read a lot of discussions in the vscode repo about supporting something like this before. Besides sounding very cool, my conclusion is that such modularity enables a great deal of configurability for users and extension authors.

One of the things that come to mind, is to allow users to configure/ extend their own key chords or even emulate modal editing behavior akin to Vim. I myself tried at some point, to improve my keybindings by creating an extension (which I don't use anymore), but because of vscode's limitations, this is simply to difficult to achieve.

If I understood the proposal correctly, I for instance would use this to create a "power mode" that would bring some of Helix motions to Zed without actually adopting some dreaded VIM's constraints and history. I think @Daeraxa and @hovsater are up to something here and if this gets implemented it might become something revolutionary. People could even create and share keybindings configurations with opinionated defaults as Zed "flavors". I really like this idea! 👍

[Uizoh]

I'm quite surprised someone else thought exactly what I was thinking.

It will be great to have a modal code editor like Helix to be intergrated into Zed. Since I like their philosophy more(action after selection). I feel like this could help the Helix community to grow as well. Neovim already has a good number of community managed GUI editors. Most notably neovide. I'd like to see Zed editor being the GUI of Helix. I'm speaking for both communities here.

[Daeraxa]

I'm not necessarily sure it should be a frontend for Helix, more just expressing that I would like to see Helix-like or at least another form of modal editing that is fully integrated into the frontend of Zed rather than just being stuck with Vim which often only features the strictly editing aspects and doesn't interact with the rest of the application.

It is worth noting that Helix do plan to add a GUI mode of their own, the tracking issue for it was literally created by Zed's @Kethku who also made Neovide.

[Uizoh]

I'm not necessarily sure it should be a frontend for Helix

I was just stating what was in my mind. It doesn't necessarily mean Helix should have Zed as a front end. It could be nice if it works out that way.

It is worth noting that Helix do plan to add a GUI mode of their own, the tracking issue for it was literally created by Zed's @Kethku who also made Neovide.

Aha.. how come I didn't see that lol. I knew the profile seemed familiar. Good to know such skillful individual is working on this project.

[adriangalilea]

Any updates on this?

[feltcute]

Big exploratory writeup on the world of Treesitter bindings below. I presume this is a good spot for it? Will gladly move elsewhere if not.

The most potent example I've seen of seeing something as intriguing "Post-Vim" modal editing, is Helix adding out of the box support for treesitter selection/navigation, and innate easymotions. That minimal barrier to beating the mouse in editing flexibility and flow is personally my priority over the power of motion editing itself. Which is where the appeal of "Post-Vim" modal editing is for me, reducing mental load to proficiently exploit the power of modal editing to reach that junction point. And I see Zed with Treesitter as real close in potential to lead in the gui editor pack, even without diving into its Vim mode.

Zed recently got a taste of more treesitter based editing with syntax node scope selection, which I've enjoyed using, love mrnugget's work on that.

Though I do see potential for more power out of this. Some Zed issues on selection of Syntax Nodes I found appealing:

• Arbitrary keybinding of syntax node selection, I'd like being able to finetune it for usecases using inner/outer and before/after, there's often situations where you want to select to the left or right of the cursor, with or without the delimiters.
• Navigating syntax node selection by a count, as it'd be nice to not spam the expand/shrink keybinds that may not be the most convenient on all user keymaps.

A big rather related one from Helix absent in Zed is Select previous sibling node in syntax tree, Select next sibling node in syntax tree and more debatably Select all sibling nodes in syntax tree, so you can easily select multiple sibling entries in the syntax tree without pulling out a regex or the likes. Hopefully also with navigation by count as seen above linked 17245, as it'd arguably need it more than parent/child selection for something like keys in a dictionary.

It isn't just about selection in Helix, there is also the Vim Unimpaired inspired treesitter bindings under the (TS) label. As far as I could find, Unimpaired nor Zed expose using treesitter to go to next/previous func, comment, type definition, argument/parameter, and tests. And less treesitter related, but jumping between git changes. I'd find this really powerful comboing this with the selection features above.

Though there's a reason I am here rather than in an issue kindly asking for support for Helix's additional treesitter keybinds. And that was, looking at the timeline of these feature additions to Helix, they were all technically, afterthoughts, in what is an editor really about rethinking Kakoune's style to something a bit more vim-like. The new treesitter bindings weren't innate to the design of Helix. They still feel easy to use, but it doesn't feel fully explored, nor prioritized as first class in Helix bindings. While I know I'd enjoy them ported to Zed even as manually binded keybinds largely as-is, I've wondered if there's a more encompassing concept to using treesitter based navigation/selection that could be had.

And then I saw the Ki Editor.

Ki thinks through using treesitter as the forefront tech to define its new modal editing approach and bindings. Its ultimate demonstration of power to me, is that its file explorer is literally YAML, letting it largely reuse its bindings to get the job done.

I was super pumped to toy with it, up till I realized it has no keybind config (the creator announced plans to address this), a no go when I use arrow keys on esdf in a homerow'd layer, rather than hjkl. I also am getting into Zed because it isn't a TUI, as useful as TUIs can be.

Other cool advancements Ki makes is first/last sibling, parent line (note the tip of how the yaml file explorer uses it), and how its modal layout gets to be so incredibly tiny in bindings compared to Vim and Helix. One might chalk that up to how young it is, as the author is still expanding its feature set, though I did find their testimony and visual demonstrations rather convincing in its usability today. I think it gets well past that better-than-mouse junction point I look for, with much lower knowledge overhead, provided you know syntax of the language you're coding in.

All to say, it gave me much pause on the idea of opening up an issue on adding these treesitter features from Helix. Individually useful treesitter bindings that lifts all vim, helix, and non-modal boats. Or, a modal editing setup that tries to fully capitalize on it? I'm afraid my ability to power use vim and helix isn't quite as advanced as others, so I'd be keen to know what stronger power users would think of Ki in comparison to some treesitter binding additions. Or maybe they too are stuck on a no-go of no keybind configs or GUI as I am to be able to give it its fair shot. I also may be underestimating or overestimating how much Zed can take on at a time in regards to currently niche treesitter-nav/selection features, with no need to deliberate it as a one or the other theoretical.

[feltcute]

The documentation recently got revamped, so I updated the links. The new tutorial section gives a good picture for those wanting an in practice taste of the bindings in action without trying for oneself.

One can see in the repo that it is definitely still going through some fundamental iterations to its modal.

Adding yet another modal editing experience like how #17575 is being done would be asking for doing something like VS Code's generic modal implementation ecosystem, explored in comments elsewhere here. Hopefully enabling modals like Ki is kept in mind for such an effort in the future. Primarily relying on exposing three pillars:

• Thorough treesitter exposure
• Selection first support (it isn't reliant on just syntax nodes)
• Exposing other UI components aside from the text field to the bindings for better enabling key mapping coherency.

In the meanwhile, smaller scale replication of giving Zed/Vim/Helix users the existing Helix treesitter keybinds to existing modal mode(s) and standard text editing is probably more near term feasible and in-scope till Zed reaches a comfortable user target per nathansobo's comment for exploring beyond existing popular modals.

[B4Dmonkey]

"And then I saw ki"

Excellent write up, I was recently introduced to helix (about a week in on my journey) and I immediately liked it but what I'm really looking for is the next evolution of vim. I've spent the past year operating in vim motions on vscode and while I feel comfortable moving around I don't feel like a "power user". I think this is because the rabbit hole of options goes deep.

I'm gravitated towards helix selection -> action model. I often find myself undoing commands when using vim. After reading your post about ki though, something like that could be promising. Without a full understanding Ki's bindings I don't know if its the correct direction but I do think learnings can be gained from it helix and Kakoune for designing something unique to zed? Note I haven't used Kakoune but my understanding is that helix is inspired from it. One thing that interest me is that theres one less mode