Option to exclude mappings

[lverweijen]

For instance, to exclude mappings that start with b and f, put this in vimrc:

let g:spacevim_exclude="bf"

[ctjhoa]

Hi,

I'm not totally statisfy with this solution as it's very intrusive in the code and not really flexible. So I've done some work on this, here is what I've got now.

Excluded bindings are declared as a list of regex which avoid confusion and is more readable plus you can exclude one specific binding.

let g:spacevim_exclude_key_binding = ['b.*', 'f.*']

One drawback that I've got for now is that categories are not hidden in vim leader guide but you are not using vim leader guide if I'm correct ;)

Is it OK for you?

[ctjhoa]

My code is in exclude_binding branch

[lverweijen]

Excluded bindings are declared as a list of regex which avoid confusion and is more readable plus > you can exclude one specific binding.

let g:spacevim_exclude_keybinding = ['b.', 'f._']

Maybe a single regex is enough as you can always combine them with '|'. For example:

function! s:spacevim_is_binding_enabled(binding)
    return a:binding !~ spacevim_exclude_key_binding
endfunction

let g_spacevim_exclude_key_binding = '^(b.*\|f.*)$'

One drawback that I've got for now is that categories are not hidden in vim leader guide but you are not using vim leader guide if I'm correct ;)

I would like this to work again. I temporarily disabled leaderguide in my personal configuration, because I was having some problems with it, but hope to enable it again once I have solved those.

[lverweijen]

I took a look at your 'devel' branch and saw that my original pull request is similar to your layer system with two exceptions:

• In my pull request every mapping is part of a layer
• You install plugins

If 1 were to be added to your layer system (for example a separate layer for f mappings, like you already have a layer for g mappings), I think this pull request is no longer necessary.

Furthermore, I think that #17 is a nice way to block single mappings a user doesn't want.

[ctjhoa]

Ok so here is the status of my dev branch. I handle plugin installation but I'm not totally statisfy with the link between "plugin installation" and "key bindings". Layers in spacemacs are separate directories and each layer contains associated plugins and associated key bindings.

Anyway, for the moment, my core layer is monolithic. I think that it will be difficult to split it because many plugins are used in several categories of key bindings (eg. fzf is used in +buffers, +files and the root)

So I've done some sort of port of my exclude_binding branch in the dev branch. I've also improved it as now the categories are excluded too.

If you have a alternative solution we could talk about it but I don't see any now.

[lverweijen]

Ok so here is the status of my dev branch. I handle plugin installation but I'm not totally statisfy with the link between "plugin installation" and "key bindings". Layers in spacemacs are separate directories and each layer contains associated plugins and associated key bindings.

It seems you want to directly tie layers to plugins to install. Then you might want them to have them separate. For me, the purpose of spacevim is just a convenient way to setup some keybindings.

Anyway, for the moment, my core layer is monolithic. I think that it will be difficult to split it because many plugins are used in several categories of key bindings (eg. fzf is used in +buffers, +files and the root)

If you follow the idea of unifying layers and categories, fzf would have to be installed if at least one layer/category is enabled that uses it, but if you use it in the root, it needs to be installed anyway.

So I've done some sort of port of my exclude_binding branch in the dev branch. I've also improved it as now the categories are excluded too.

It looks good. I'm just a bit sceptical about what would happen to the loading time if you have to do this for 1000 potential keybindings (but that needs to be tested). If you put everything in layers, you can skip over complete groups at once. That's why I like putting everything in layers. It also gives you a single mechanism to enable/disable stuff.

The disadvantages of unifying layers and categories are a weaker correspondence between layers and plugins (multiple layers install the same plugin) and being less faithful to spacemacs (we would have more layers than they).

[ctjhoa]

It seems you want to directly tie layers to plugins to install. Then you might want them to have them separate. For me, the purpose of spacevim is just a convenient way to setup some keybindings.

Not exactly, with the 2.0 version I want to provide 2 mode.

One "distribution mode" which will be a vim distribution batteries included like Spacemacs is for emacs. And an "advanced mode" which provides only key bindings like now.

If you follow the idea of unifying layers and categories, fzf would have to be installed if at least one layer/category is enabled that uses it, but if you use it in the root, it needs to be installed anyway.

You gave me an idea with that. Let me try something. I'll keep you in touch

[ctjhoa]

OK. Now I've got something almost stable in my dev branch tell me what you think of that.

[lverweijen]

I think it looks great

[ctjhoa]

No need for this anymore