bind comamd for mode from leader key not just mode leader key

[thanhvg]

Currently spacemacs/set-leader-keys-for-major-mode and spacemacs/set-leader-keys-for-minor-mode only let us bind command under spc m and , That works fine in general. But not all commands should go there. A mode that deal with compilation or comments when active should have commands bound behind spc c not spc m. Another example is org-mode narrow commands should go to prefix spc n not a long and tedious spc m s b n.

It would be easy to implement if spacemacs only supported evil. But it is possible anyway. I think I'd have to create some mouthful functions spacemacs/set-root-leader-keys--for-major-modeand spacemacs/set-root-leader-keys-for-minor-mode. It is also involved bind-map to create two extra keymaps for each mode of interest which I am not sure about the performance impact.

[dalanicolai]

I think the general design is, like you mentioned, to put major mode bindings behind ,. So where you mention the SPC c and SPC n alternatives, that should probably be , c and , n alternatives. If commands are local to some mode they should NOT be bound behind SPC. If , n is still available in org-mode (which I think it is), then you could propose to move narrow commands there.

Also, I think in most layers implementing modes that provide compilation commands, those commands are bound behind , c already (e.g. latex, c-c++ layers). The , c option might not show up in the c-c++-layer and there is probably some (un)acceptable reason for that.
It would be nice if another binding for the quickrun command would be added to the c-c++-layer b.t.w. (and possibly to many other layers).

What do you mean with "if Spacemacs only supported evil"?

[lebensterben]

So where you mention the SPC c and SPC n alternatives, that should probably be , c and , n alternatives

I prefer to stick to , prefix.
But the issue is for some major modes , c or , n are specialised and differ from generic cases.

For example in Rust mode , c is tied to cargo related commands, which happen to include compilation, but also includes a lot more.

Probably, we can have the following conventions:

• , contains major mode key bindings.
• , , contains 'alternative' major mode bindings.

[thanhvg]

I think the general design is, like you mentioned, to put major mode bindings behind ,. So where you mention the SPC c and SPC n alternatives, that should probably be , c and , n alternatives. If commands are local to some mode they should NOT be bound behind SPC. If , n is still available in org-mode (which I think it is), then you could propose to move narrow commands there.

Also, I think in most layers implementing modes that provide compilation commands, those commands are bound behind , c already (e.g. latex, c-c++ layers). The , c option might not show up in the c-c++-layer and there is probably some (un)acceptable reason for that.

We are binding keys by modes not by features. We should do the other way around.

In Spacemacs major modes are behind , but minor modes can bind anywhere. It looks nice in writing its documentation because key bindings are well organized by modes. But it is not so great for users. I am a user I think of features I want to use not by an emacs mode active or not. If a major mode provides a compilation feature why can it just bind to SPC c blah blah instead of , c?. Why can't users just go to one place SPC c for compilation features without worrying about the features they want may be bound somewhere else?.

I understand the principle for , major mode which is great to avoid collision of key bindings. But it can be absurd if we keep sticking to it all the time. I am on an org buffer and I want a narrow function, why do I have to go to separate ways: SPC n or , blah blah?. In vanilla emacs all narrow functions are bound behind C-x n when you are in org mode, extra functions to narrow org buffers are there too.

Had org-mode narrow functions followed our Spacemacs principle the binding would be like C-c C-blah blah which is not useful for users. And please don't get me started on how ridiculously long org-mode keybings are in Spacemacs.

SPC e is what I like in Spacemacs, everything about errors in buffer goes there. Now imagine if some major mode layer insisting on binding , e to handle errors. Actually lsp-mode layer is doing it (, g e).

All of these happened because we restrict major mode binding to ,. I want freedom for major modes.

It would be nice if another binding for the quickrun command would be added to the c-c++-layer b.t.w. (and possibly to many other layers).

Adding quickrun to Spacmacs is not a problem. But the problem is the binding: SPC c or , c? Either way makes sense. We just brought ourselves a unnecessary dilemma.

What do you mean with "if Spacemacs only supported evil"?

It is easy to bind to SPC / M-m with evil. But we support vanila emacs style too so we need bindmap to do it but anyway it was easier than I expected.

See my PR here #14422

[dalanicolai]

In case of narrow functions, I think I prefer to find the narrow functions specialized to the major-mode under ,.
It could be moved to , n but I would not like to mix them up with general narrow commands.

Also I prefer to have compile commands under , c instead of SPC c C, and a quickrun binding could be added under SPC, like other commands that adapt their behavior to current 'major-mode' (like e.g. SPC j i).