feature: add keymap group for lazy.nvim, mason, treesitter etc.
Did you check the docs?
- [X] I have read all the LazyVim docs
Is your feature request related to a problem? Please describe.
it's not a problem but it would be nice if it was provided by default in LazyVim, since I am lazy.
Describe the solution you'd like
when I periodically update packages, it would have been nice if there was a key group for all package managers that are used, I am thinking of lazy.nvim, mason and treesitter.
For example, <leader>+l and +L are for lazy.nvim and I understand why they are prioritized and given their own letter on the first level, but there are more components that you probably want to open to update/install packages and show logs, etc.
Whether it should be a key-group for just package managers or for general settings with package managers as a subgroup, I don't know.
Describe alternatives you've considered
I could map it myself but I really like the consensus by the community for key bindings, so I don't have to change it 6 months later 😉
Additional context
First of all, I want to thank you and contributors for the work with LazyVim and all the other products you build. I've been using and configuring Neovim, mostly for Java, for some years now but It never ends and I always had the feeling that I was behind. In the end, it was too much configuration and too little actual coding so I decided to switch to LazyVim and put my mind at ease. LazyVim is, in my opinion, the best packaging of Neovim with clear configuration and extension points.
Standing on the shoulders of giants.
This is what I did. "Vin" because thats how I "named" my config.
Link: https://github.com/nikbrunner/lazyvin/blob/53adff36f032a203caca751deb9721974208946e/lua/config/keymaps.lua#L41
local lazyvim_util = require("lazyvim.util")
local set = vim.keymap.set
local del = vim.keymap.del
-- ...
-- Vin Group
-- Delete LazyVim default bindings
del("n", "<leader>l")
del("n", "<leader>L")
set("n", "<leader>vP", "<cmd>Mason<CR>", { desc = "Package Manager - [Mason]" })
set("n", "<leader>vp", "<cmd>Lazy<CR>", { desc = "Plugin Manager - [LazyVim]" })
set("n", "<leader>ve", "<cmd>LazyExtras<CR>", { desc = "Extras Manager - [LazyVim]" })
set("n", "<leader>vi", "<cmd>LspInfo<CR>", { desc = "Lsp Info" })
set("n", "<leader>vc", lazyvim_util.news.changelog, { desc = "Changelog [LazyVim]" })
set("n", "<leader>vr", lazyvim_util.root.info, { desc = "Root Info [LazyVim]" })
set("n", "<leader>vM", vim.cmd.messages, { desc = "Display messages" })
I think having a default group is better. of course I can map it myself, but you never know when your custom shortcut will conflict with other new shortcuts.
Your custom keymaps will take precedence over default ones. I don't believe this is needed in my personal opinion as a simple user.
Your custom keymaps will take precedence over default ones. I don't believe this is needed in my personal opinion as a simple user.
yes, you are right. custom mappings take precedence. However, here is a problem. when I add a new extra plugin, it's because I want to use it. At this point, I can only choose to modify my custom shortcuts and adapt to then again.
so, I think a better approach might be maintain a shortcuts group in extra and users can choose according to their needs.
That will always happen in a distro as more Extras are added. And not all users use the same kind of thinking in their personal configuration, so eventually there is bound to be a conflict somewhere. That's why users have the freedom to customize their personal configuration however they see fit.
In my personal opinion as a regular user like you, that should be left up to the user.
However, I think having a unified entry point for different managers is a relatively common requirement. Therefore, if the default settings can reserve a shortcut for this unified entry point, it can effectively avoid conflict issues. Users would only need to override this reserved shortcut.
However, I think having a unified entry point for different managers is a relatively common requirement.
Requirement by who? It's just personal preference. It's just Lazy and Mason. Lazy has a top level keymap as the main package manager and Mason is under coding. Nobody's stopping you from doing whatever you want in your personal configuration. Just overwrite <leader>l which is used by Lazy and make it your entry point. I doubt you will have conflicts by doing that in the future.
At least here are seven people have same requirement. And I have already had conflicts twice. That's why I think it's better to have a default shotcut.
You are both right, there is no "one size fits all", it's all about preferences. But I'm also thinking that it might not be such a bad idea if Lazyvim could reserve a letter for personal key bindings.
The reason I wrote this request was that I felt the need to create a group for "settings". Since we don't have infinite characters, it felt unnecessary to use both L and l for Lazy things. Instead, e.g. leader+L could be a group for Lazy Settings that contains Lazy related things. While waiting for this issue to be resolved I created a group under leader+; which then contains Lazy, LazyExtras, Mason, LspInfo, LazyVim Changelog, Display Massages.
For my "personal" keybindings I am using <localleader>, and I know it is not the intention of local leader but it works for me 😉
@merikan Why don't you just delete <leader>L from keymaps and then assign it to your personal configuration to whatever you want? This worked for me for what you want to achieve
-- ~/.config/nvim/lua/config/keymaps.lua
vim.keymap.del("n", "<leader>L")
vim.keymap.set("n", "<leader>Ll", "<cmd>Lazy<cr>", { desc = "Lazy" })
vim.keymap.set("n", "<leader>LL", function()
LazyVim.news.changelog()
end, { desc = "LazyVim Changelog" })
-- ~/.config/nvim/lua/plugins/which.lua
return {
{
"folke/which-key.nvim",
opts = {
defaults = {
["<leader>L"] = { name = "+Lazy Settings" },
},
},
},
}
This way I doubt you'll have any conflict, since you're overriding a default LazyVim top-level keymap, which I doubt will change.
I'm saying this because I've been using LazyVim for a long time and gotten used to LazyVim default keymaps (Mason and LspInfo are under code which seem pretty reasonable to me). The default LazyVim configuration only uses 17 letters as top-level keymaps (not including the Extras, which most of the time use some already defined group, for example the Python and Rust Extra I use has keybindings in already defined groups), so there are still a lot for the end user to use for whatever they like.
To me what you're asking looks like a different preference of organizing things, which should be left up to the user in my personal opinion.
PS: Of course, this is just my personal opinion as a regular user like you and the maintainer has the final say.
@merikan Why don't you just delete
<leader>Lfrom keymaps and then assign it to your personal configuration to whatever you want? This worked for me for what you want to achieve
I did delete <leader>L and <leader>l and added <leader>; for my settings group.
-- ~/.config/nvim/lua/config/keymaps.lua vim.keymap.del("n", "<leader>L") vim.keymap.set("n", "<leader>Ll", "<cmd>Lazy<cr>", { desc = "Lazy" }) vim.keymap.set("n", "<leader>LL", function() LazyVim.news.changelog() end, { desc = "LazyVim Changelog" })-- ~/.config/nvim/lua/plugins/which.lua return { { "folke/which-key.nvim", opts = { defaults = { ["<leader>L"] = { name = "+Lazy Settings" }, }, }, }, }This way I doubt you'll have any conflict, since you're overriding a default LazyVim top-level keymap, which I doubt will change.
but this is exactly what I asked for in this issue, to change +l and +L.
I'm saying this because I've been using LazyVim for a long time and gotten used to LazyVim default keymaps (
MasonandLspInfoare undercodewhich seem pretty reasonable to me). The default LazyVim configuration only uses 17 letters as top-level keymaps (not including the Extras, which most of the time use some already defined group, for example the Python and Rust Extra I use has keybindings in already defined groups), so there are still a lot for the end user to use for whatever they like.
Sure, you can always discuss where things belong and I agree that LspInfo also might belong under code, like you have done but it is not a default mapping. This issue was about when I manage my environment, e.g. update packages, update plugins, check logs, read changelog, maybe troubleshoot settings etc.
To me what you're asking looks like a different preference of organizing things, which should be left up to the user in my personal opinion.
I don't understand what you mean, I have no intention of reorganizing things. All I asked for was to, instead of occupying two characters at the top-level (+L, and put settings there (Lazy things and other stuff).
PS: Of course, this is just my personal opinion as a regular user like you and the maintainer has the final say.
That was what I was asking for, the consensus by the community for this key binding. 😉
The consensus by the community you're talking about is not actually that concrete a definition, because in my experience people tend to talk more about things they don't like instead of things they like. So, the people that have spoken here are not indicative to me as the consensus by the community. Just to clarify, I don't mean people's opinions in this thread should be discarded. Just that the term consensus by the community can be rather broad and not easily verifiable in concrete terms.
The LspInfo keymap is indeed a default keymap and is under code by default.
In the end the maintainer will also make a personal decision about this, because as is quite apparent from different Neovim distros, they all have some preference bias depending on the people who created them, as is quite logical to me.
The consensus by the community you're talking about is not actually that concrete a definition, because in my experience people tend to talk more about things they don't like instead of things they like. So, the people that have spoken here are not indicative to me as the consensus by the community. Just to clarify, I don't mean people's opinions in this thread should be discarded. Just that the term
consensus by the communitycan be rather broad and not easily verifiable in concrete terms.
What I meant with 'consensus' was that I wanted to the community (maintaners/commiters) decide since I don't have all the information. I'm not here to argue semantics so I guess I'll leave it at that.
The
LspInfokeymap is indeed a default keymap and is undercodeby default.
You are right, I totally missed that. 😉
In the end the maintainer will also make a personal decision about this, because as is quite apparent from different Neovim distros, they all have some preference bias depending on the people who created them, as is quite logical to me.
I agree on that.
Oh my bad on the consensus thing then. English is not my mother language, so i took it literally and failed to understand the context. Apologies for that.
I don't see the need to make these changes right now
Oh my bad on the consensus thing then. English is not my mother language, so i took it literally and failed to understand the context. Apologies for that.
@dpetka2001 it's totally ok, there's no need to apologize. English is also not my native language. 😁
Anyway, the issue is closed so we should use our own preferences. I just remapped from <leader>; to <leader>L, like you suggested, it felt more ..... Lazy 😉
Take care and have a great day.