use buffer only mappings when possible

[kylo252]

We could use a simple function

on_attach = function(_, bufnr)
    local nmap = function(lhs, rhs, desc)
      if desc then
        desc = desc
      end

      vim.keymap.set("n", lhs, rhs, { silent = true, desc = desc, buffer = bufnr, noremap = true })
    end

    local jtdls = require('jdtls')
    nmap("<leader>Jo", jdtls.organize_imports, "organize imports")
    nmap("<leader>Jv", jdtls.extract_variable, "extract variable")
    -- ...
end

[vitorf7]

@kylo252 would it not be better to make use of the ftplugin/{filetype}.lua pattern in this case? It would be consistent with what we first started doing in all IDEs.

[kylo252]

@kylo252 would it not be better to make use of the ftplugin/{filetype}.lua pattern in this case? It would be consistent with what we first started doing in all IDEs.

the problem is that we can't move all the configuration there, mostly because of limitations with packer.

I'd love some ideas on how to solve on-demand plugin installations. I experimented a bit with it here: https://github.com/kylo252/LunarVim/tree/defer-plugin-loader but I'm not happy with complexity trade-offs, I'm worried that people may not find it intuitive enough, since it needs to have restrictions (can't use any/most lvim vars)

[vitorf7]

the problem is that we can't move all the configuration there, mostly because of limitations with packer.

Oh sorry, I meant mainly moving the which-key keymaps should potentially all be moved to the ftplugin/{filetype}.lua files. I say this because not only are which-key mappings more elegant and readable (as opposed to have to register them manually using the vim.keymap.set) since you can have them well laid out into multi levels, but especially in LunarVim where you don't necessarily need call require("which-key").register() again.

I think this would make each starter package very consistent in that if you were to code in java and go as an example, you could pull in both starters and the keymaps would all live in ftplugin/java.lua and ftplugin/go.lua respectively. I think that would be intuitive, elegant (for the reasons laid out before).

Yeah as for plugins I can understand that it be a bit more difficult. When I first tried to do my go ide starter package I was using something like:

vim.tbl_extend("force", lvim.plugins, {
-- Specific plugins here
})
``
I am not as knowledgeable as you on vim/neovim and especially lunarvim though, so maybe I am committing some crazy best practices sin or doing something wrong.

[kylo252]

but especially in LunarVim where you don't necessarily need call require("which-key").register() again.

unfortunately, this isn't actually a thing, what is possible is using a plugin file instead, since running the entire lvim.builtin.whichkey on ftplugin will probably be pretty expensive.

again, I'd love any suggestions on how to handle this! I think it's all doable except for anything to do with Packer, since it basically acts like one big singleton :smiling_face_with_tear:

I am not as knowledgeable as you on vim/neovim and especially lunarvim though

you can refer to :h 'runtimepath' to check how the loading order works, but here's a small demo

cd ~/.config/lvim
mkdir -p plugin ftpugin after/plugin

echo "print('hello from config.lua')" >> config.lua
echo "print('hello from plugin/test.lua')" >> plugin/test.lua
echo "print('hello from after/plugin/test.lua')" >> after/plugin/test.lua
echo "print('hello from ftplugin/python.lua')" >> ftplugin/python.lua

echo 'print(1+1)' > dummy.py

# this will run neovim in headless mode and run the command 'quitall' after loading the first file 
lvim --headless +'quitall' dummy.py

[LostNeophyte]

Folke is using conds in whichkey to enable mappings conditionally (it's not dynamic though) and calling wk.register (with bufnr option) in LSP's on_attach, what about doing the same? we don't need to register lvim.builtin.whichkey, just the buffer local mappings.

[kylo252]

Folke is using conds in whichkey to enable mappings conditionally (it's not dynamic though) and calling wk.register (with bufnr option) in LSP's on_attach, what about doing the same? we don't need to register lvim.builtin.whichkey, just the buffer local mappings.

doesn't that mean you'd have to have one big table with all the keymaps for all the servers? or what did you have in mind

[LostNeophyte]

doesn't that mean you'd have to have one big table with all the keymaps for all the servers? or what did you have in mind

it does, unless we don't use conds and just the buffer option in wk.register