LazyVim icon indicating copy to clipboard operation
LazyVim copied to clipboard

feature: add keymap group for lazy.nvim, mason, treesitter etc.

Open merikan opened this issue 2 years ago • 1 comments

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.

merikan avatar Oct 19 '23 09:10 merikan

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" })

nikbrunner avatar Oct 19 '23 13:10 nikbrunner

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.

leisurelicht avatar Jun 03 '24 07:06 leisurelicht

Your custom keymaps will take precedence over default ones. I don't believe this is needed in my personal opinion as a simple user.

dpetka2001 avatar Jun 03 '24 07:06 dpetka2001

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.

leisurelicht avatar Jun 04 '24 08:06 leisurelicht

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.

dpetka2001 avatar Jun 04 '24 08:06 dpetka2001

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.

leisurelicht avatar Jun 05 '24 03:06 leisurelicht

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.

dpetka2001 avatar Jun 05 '24 04:06 dpetka2001

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.

leisurelicht avatar Jun 05 '24 06:06 leisurelicht

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 avatar Jun 05 '24 07:06 merikan

@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.

dpetka2001 avatar Jun 05 '24 09:06 dpetka2001

@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

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 (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.

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 +L), group them together under one character i.e +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. 😉

merikan avatar Jun 05 '24 11:06 merikan

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.

dpetka2001 avatar Jun 05 '24 12:06 dpetka2001

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.

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 LspInfo keymap is indeed a default keymap and is under code by 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.

merikan avatar Jun 05 '24 13:06 merikan

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 avatar Jun 05 '24 13:06 dpetka2001

I don't see the need to make these changes right now

folke avatar Jun 05 '24 21:06 folke

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.

merikan avatar Jun 06 '24 07:06 merikan