Native mapping syntax | Need feedback & v2.5 🚀

[siduck]

Hi everyone I need feedback with the new potential mapping syntax which could be used from v3.0.

Currently you all have to read this custom syntax

["<C-n>"] = {"<cmd> NvimTreeToggle <CR>", "Toggle nvimtree"},
[";"] = { ":", "enter cmdline", opts = { nowait = true } },

["<leader>tt"] = {
  function()
     require("base46").toggle_transparency()
  end,
  "toggle transparency",
},

With the new syntax, which just uses Neovim's default vim.keymap.set function

map("i", "<C-k>", "<Up>", { desc = "Move up" })
map({ "i", "n" }, "<C-k>", "<Up>", { desc = "Move down" })
map("n", "<leader>ff", ":Telescope <cr>", { desc = "Telescope find files" })

map("n", "<A-i>", function()
  require("nvchad.term").toggle()
end, { desc = "Terminal toggle floating" })

So the first word is used for group name in nvcheatsheet , You can just write a wrapper of vim.keymap.set to simplify things even more

so to override a default mapping or add new one, you just put the vim.keymap.set code in custom.mappings.

And to disable one mapping, just use vim.keymap.del

Pros of this method

1. Dont have to learn custom syntax for mapping + using nvim's inbuilt functions.
2. You can set a mapping to multiple modes at the same time.
3. This removes a lot of abstraction & also LOC from our codebase, the only 2 big functions we had in our core where for handling this custom mapping syntax 😱

Cons

• Will be a breaking change as it'd be added in v3.0. But dont worry you can still use v2.0 and take your time to migrate to v3.0.

So please let me know if you like this method. Add a 👍 if you do or 👎 if you dont.

Btw do know that you can still use old syntax with some lua coding! check #2688 (comment)

[nautrw]

Personally, it wouldn't matter much to me but I think the one that is already in place is fine

[siduck]

Personally, it wouldn't matter much to me but I think the one that is already in place is fine

the issue with that is that you have to learn 2 syntaxes. One for vim.keymap.set & its opts and the other for nvchad's custom mapping syntax.

[nautrw]

But it's already pretty intuitive and (correct me if I'm wrong) matches with whickey.nvim

[magency-prod]

I like the old approach, which makes mapping configuration very readable. A hybrid approach of allowing both might be a good idea too.

[siduck]

I like the old approach, which makes mapping configuration very readable. A hybrid approach of allowing both might be a good idea too.

local map = vim.keymap.set

local mappings = {
  n = {
    ["<C-n>"] = { "<cmd> NvimTreeToggle <CR>", "Toggle nvimtree" },
    ["<C-i>"] = { "<cmd> NvimTreeToggle <CR>", "Toggle nvimtree" },
    ["<C-b>"] = { "<cmd> NvimTreeToggle <CR>", "Toggle nvimtree" },
  },
}

for mode, maps in pairs(mappings) do
  for key, val in pairs(maps) do
    map(mode, key, val[1], val[2])
  end
end

With new approach you can define any syntax you want 😁

[jotihojr]

I like the old approach, which makes mapping configuration very readable. A hybrid approach of allowing both might be a good idea too.

I too find the current approach very good. I would most certainly refrain from putting grouping information (i.e. | word) in descriptions:

1. results in key-binding descriptions being adversely terse and I foresee formatting problems with whichkey
2. putting controlling information in descriptions has always been problematic: end users don't always do as expected

However, implementing grouping is a good idea and could be done without breaking changes using the current format -> an additional optional field passed to whichkey.

[siduck]

@jotihojr | is optional but i'll include them in default mappings

I agree that this would clutter whichkey a little but adding| is the only way through which we could group them in nvcheatsheet whilst still using vim.keymap.set

You can still reset them tho. like this

local mappings = vim.api.nvim_get_keymap("n")
local map = vim.keymap.set

for _, v in ipairs(mappings) do
   -- get word before |
   local desc = v.desc:match("([^|]+)%s*|")

   map("n", v.lhs, v.rhs or v.callback, { desc = desc })
end

or I think we could could cache the groups & their keybinds in some file for nvcheatsheet and then reset the value 🤔

[jotihojr]

@jotihojr | is optional but i'll include them in default mappings

I agree that this would clutter whichkey a little but adding| is the only way through which we could group them in nvcheatsheet whilst still using vim.keymap.set

You can still reset them tho. like this

or I think we could could cache the groups & their keybinds in some file for nvcheatsheet and then reset the value 🤔

Programmatically anything is possible, but not always advantageous.
Adding " | terminal" to descriptions may give 3 instead of 4 columns and thus increase whichkey display height, reducing visible buffer area.
What if someone wants | in the description?

There's got to be a better way. Perhaps a PR @neovim adding optional grouping in vim.keymap.set.

[siduck]

There's got to be a better way. Perhaps a PR https://github.com/neovim adding optional grouping in vim.keymap.set.

I dont know C so i cant do it

[siduck]

@lucario387 is there any way? 🤔

[K4R7IK]

Will it affect the key mapping that we are passing via Lazy-vim using the keys options?

[siduck]

Will it affect the key mapping that we are passing via Lazy-vim using the keys options?

no

[siduck]

@jotihojr i think it'll be better to use group name in description as first word as it'd be better with other plugins too!!

[sandangel]

@siduck sorry I missed this issue. Currently I use this code to disable all default mappings. Is there a way to do that with new approach rather than having to define all the default mappings with vim.keymap.del?

-- Disable all default key maps
M.disabled = {}

for _, section in pairs(require('core.mappings')) do
  for mode, keys in pairs(section) do
    if mode == 'n' or mode == 't' or mode == 'v' or mode == 'x' or mode == 'i' then
      for key, _ in pairs(keys) do
        if M.disabled[mode] == nil then
          M.disabled[mode] = {}
        end
        M.disabled[mode][key] = ''
      end
    end
  end
end

[siduck]

@sandangel Btw do know that v3.0 might take months to finish as i'm not working on nvchad from march 10 to april 10. So no need to panick! Just use v2.0 for now. Also when v3.0 releases, take your own time to migrate to it,v2.0 can still be used

local disabled = {
  n = { "<C-n>", "<C-s>" },
  i = { "jk" },
}

for mode, mappings in pairs(disabled) do
  for _, keys in pairs(mappings) do
    vim.keymap.del(mode, keys)
  end
end

[sandangel]

@siduck It doesn't change the fact that I will need to list all the default mappings in the local disables = {} variable. I want to infer the current default mappings from core.mappings so I can disable all at once.

[siduck]

@sandangel you were doing the same before, whats the difference? I can only think of mapclear command. Btw if all things go right then you can opt out from default mappings when nvchad v3.0 releases

check the last line here and then check the mappings file https://github.com/NvChad/NvChad/tree/test

lazyVim and astronvim v4 have a starter config like thing in which they import their configs as plugins. By import i mean lazy.nvim's import feature. So in the above nvchad's test branch you could see, how could one use nvchad without all the custom dir stuff , just by importing nvchad as a plugin and load its stuff. This way the user has 100% control over the config :))

[CBroz1]

I fetched from v3.0 and converted my mappings to the new map(...) format. In at least one case, my mapping set in custom/ was not prioritized over one set in core/. Specifically...

map("n", "<C-n>", "<C-w>h", { desc = "Switch Window left" })

still exhibited the NvimTreeFocus behavior. Commenting out the corresponding line in core/mappings.lua fixed this issue. I assume custom > core is the intended behavior

[siduck]

@CBroz1 you should remove this line from your chadrc
M.mappings = require "custom.mappings"

[bhuynhdev]

I think I like the v3.0 mappings more. More native to VIM means you know more about what is going on, and it is easy to port someone's custom config to NvChad.

Not sure if this should be a legit concern, but IMO, with v3, need also to make sure that the expectation is correct.

Today I in v2 I tried this mapping

-- NvChad custom mappings.lua
M.lspconfig = {
  n = {
    ["<leader>ds"] = { require("telescope.builtin").lsp_document_symbols, "Document Symbols" }
  }
}

which I tried to copy from kickstart.nvim

-- kickstart init.lua
      vim.api.nvim_create_autocmd('LspAttach', {
        group = vim.api.nvim_create_augroup('kickstart-lsp-attach', { clear = true }),
        callback = function(event)
         
          vim.keymap.set('n', '<leader>ds', require('telescope.builtin').lsp_document_symbols, 'LSP [G]oto [R]eferences')
        end

My custom keymap didn't work for NvChad, due to "telescope.builtin" not loaded/existed yet when doing key-mapping. And I understood that. The different keymap syntax had the psychological effect of reminding me that NvChad works differently than Kickstart. If the syntax is very familiar, yet it works in one but not the other, I would have been quite confused.

Just my 2 cents; I am still quite a noob at Neovim. Maybe I am just overthinking this.

[siduck]

@bhuynhdev load it in a function, you dont use modules that directly cuz plugins in nvchad are lazyloaded.

so do

function() 
   require('telescope.builtin').lsp_document_symbols() 
end

btw such mappings are meant to be used on lspattach i.e if lsp client is attached to buffer. So if you were in v3.0 then u can just copy that kickstart code

local map = vim.keymap.set

vim.api.nvim_create_autocmd('LspAttach', {
  group = vim.api.nvim_create_augroup('kickstart-lsp-attach', { clear = true }),
  callback = function()
    map('n', '<leader>ds', require('telescope.builtin').lsp_document_symbols, { desc = 'LSP [G]oto [R]eferences' })

    -- add more mappings here which u want to load on buffers which have lsp attached
  end
})

[Gerodote]

I got two problems with migrating:

1. At :NvCheatsheet no mappings if a "category" has only one mapping
2. I don't remember if it was in such state: how to indent backwards selected part and don't get back to Normal, so that I stay in visual with the same selected part and I may be press the mapping again ? The mapping for indenting forward works as expected

My current config here

[siduck]

@Gerodote yes one mapping category are not allowed, plugins like surround have a lot of them... i'll probably look a better way for this soon