without modifying `init.lua`, <leader> cannot be set in time for supplied keymaps

[benfleis]

I want to try kickstart in its simple form, and be able to update it periodically.
That said, I have years of use with a different <leader>. Changing leader after init.lua loads doesn't help, as that means all the builtin keymaps use <space>, and my addon customs use another.

Proposal: inject a config call, immediately after leader (and other vim base settings) are set, giving the user a change to override those before the remaining keymaps and plugin setups run.

PR to come shortly.

[feoh]

Not an official project maintainer but I would think that for things like this you're just expected to maintain your local diffs to the provided init.lua

For instance, I'm visually impaired and can't use the onedark theme, so I just modify the file, keep the number of diffs down, and merge each new revision as it comes down from the main/master in git.

Hope this helps.

[benfleis]

I see that too, but also see a big lever from injecting a call-out at one place.
AFAICT, just inserting means I can link my init.lua to a checkout, and update away without having to merge.

The README's configuration discusses these alternatives, and 2 other places where configuration makes sense; in that context it feels quite complementary (and remains strictly opt-in, while following the pattern set by the custom.plugins call-out.)

[nivalderramas]

Hwy @tjdevries Sorry if I want to clarify.
So the appropriate way to redefine leader key would be just to edit the leader variable in init.lua and if anything changes at the upstream just merge? Thanks! :)

[fabridamicelli]

@nivalderramas
It looks like modifying lua/custom/plugins/init.lua could be a way to go without changing the default init.lua (top level).
For example, remap ' ' -> ','

vim.g.mapleader = ','
vim.g.maplocalleader = ','