zed-industries / zed

Code at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
https://zed.dev
Other
46.59k stars 2.64k forks source link

Vim: support `gn` command #4273

Closed baldwindavid closed 5 months ago

baldwindavid commented 7 months ago

Check for existing issues

Describe the feature

I'm enjoying Zed and the vim mode has really come a long way since the last I tried it. I've attempted switching to this as my full-time editor and finding that apparently my muscle-memory leverages vim's gn command extensively.

I am happy to elaborate, but VimCasts can do it more justice than I... http://vimcasts.org/episodes/operating-on-search-matches-using-gn/

Perhaps this is supported somehow in Zed of which I'm not aware. Regardless, as of now it appears the default vim keymap in Zed assigns g n already as documented at https://docs.zed.dev/general/vim#zed-specific-features...

g n   Add a visual selection for the next copy of the current word

If the intent is to eventually, as noted in the documentation, "do what you expect", the gn command is one I'd expect to be present.

If applicable, add mockups / screenshots to help present your vision of the feature

No response

ConradIrwin commented 7 months ago

@baldwindavid perhaps dangerously I made this do something slightly different in zed. It currently selects the next copy of the word under the cursor and puts you in Zed's multi-cursor mode.

I had not intended to overwrite an existing vim keybinding though, so we should probably make gn work as it does in vim; and use something else (maybe g. for the zed behavior as it's another nod to "same again")

baldwindavid commented 7 months ago

@ConradIrwin Good to know that the intention is to try to work towards "standard vim".

My two cents is that anything that is an "addition" should be under the leader key. My understanding of the Leader key has always been that it's a namespace for customization. Placing it there should remove concerns of stepping on standard vim keybindings.

Personally, I also think that most vim folk are going to customize their keybindings anyway, so just set a reasonable default under the Leader and devs can use it or map their own.

This is with the understanding that Zed doesn't actually yet have the concept of a Leader key. Even so, I think you could choose one now (I'd vote for "space"), write it into the defaults, and then update to use an actual configurable Leader at such time as it's developed in Zed.

baldwindavid commented 7 months ago

Hm, suppose if I'm talking about "standard vim" I should be suggesting \ as the leader key since that's vim's out of the box default.

mrnugget commented 7 months ago

Hey! Also ran into the same issue as @baldwindavid :) I think we could get a long way and not conflict with standard (Neo)vim keybindings if we take the nvim-lspconfig suggested keybindings as inspiration: https://github.com/neovim/nvim-lspconfig?tab=readme-ov-file#suggested-configuration

Example: g. is already taken in Zed to do code actions, so we can't use that as a replacement for gn, but if we use the suggested <space>ca it would work. (I also remember that at some point ga was the suggested keybinding). Quick Sourcegraph search suggests that people use wildly different bindings though: https://sourcegraph.com/search?q=context:global+lang:lua+vim.lsp.buf.code_action&patternType=standard&sm=1

ConradIrwin commented 7 months ago

Makes sense. My goal was to use keybindings that feel vim-native for zed-native stuff (though maybe a fools errand because there's not a lot of room left!). In particular I wanted to avoid binding to common <leader> keys (, and space) because that seems like what plugins/user config should do.

For something as useful as multicursor, it still seems nice to have a two-character binding. We could try riffing in a few directions:

My preference would probably be gs or gl, and then implement gn like vim. But open to other ideas.

mrnugget commented 7 months ago

My vote for gl -- that seems really nice to type.

(Note: g s is already taken for opening the document's symbols, right?)

baldwindavid commented 7 months ago

TIL about gs ("sleep") ha gl sounds good to me.

I'd just mention that maybe someday it'd be real nice if someone could choose a mode that is not "vim". For instance, my preferred mode is actually Helix (which is mostly Kakoune). One could argue if Helix is a "mode" or a pre-configured editor; I'd say it's a mode because that's the only one they have, but I digress.

Zed's job is tougher because it's trying to support at least two modes: vim and, uh, not-vim. It will only get tougher if attempting to support more modes. Anyway, part of me thinks that the more clearly a distinction can be drawn between a stock "mode" (vim, helix, kak) and Zed-specific keybindings perhaps the easier to reason about. On the other hand, I can appreciate trying to offer users a nice out-of-the-box vim-ish experience because you're trying to gain VSCode and Vim marketshare "today".

algora-pbc commented 5 months ago

💎 baldwindavid is offering a $100 bounty for this issue 👉 Got a pull request resolving this? Claim the bounty by adding @algora-pbc /claim #4273 in the PR body and joining algora.io

joaquin30 commented 5 months ago

Hi, so for earning the bounty I need to rebind gn to gl and implement gn vim original funcionality, right?

baldwindavid commented 5 months ago

Hi @joaquin30 ! It's solely about matching the functionality of the gn command provided by vim.

As for rebinding vim::SelectNext/Previous, the gl keybind seems fine, but I'd leave that decision up to @ConradIrwin and @mrnugget .

ConradIrwin commented 5 months ago

Yup, we should change the current gn to gl

algora-pbc commented 5 months ago

🎉🎈 @joaquin30 has been awarded $100 by @baldwindavid! 🎈🎊

baldwindavid commented 5 months ago

Really great work! My perception is that the gn command is very underrated/utilized, but it's incredibly useful for my workflow. Thanks so much.