Closed baldwindavid closed 5 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")
@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.
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.
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
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:
g z
, g x
, g c
are all open (though I type g with my left hand so on a standard keyboard they're fiddly), as are g y
, g p
and g l
(easier to type).g s
is "sleep" in vim mode; and I'd feel comfortable overwriting that...<option-v>
and <option-shift-v>
(it's a new visual mode that vim doesn't have, though it's a bit of a pain to type)<ctrl-n>
My preference would probably be gs
or gl
, and then implement gn
like vim. But open to other ideas.
My vote for gl
-- that seems really nice to type.
(Note: g s
is already taken for opening the document's symbols, right?)
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".
💎 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
Hi, so for earning the bounty I need to rebind gn
to gl
and implement gn
vim original funcionality, right?
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 .
Yup, we should change the current gn to gl
🎉🎈 @joaquin30 has been awarded $100 by @baldwindavid! 🎈🎊
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.
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...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