Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

evil-leader -> bind-map #3860

Closed
wants to merge 6 commits into from
Closed

evil-leader -> bind-map #3860

wants to merge 6 commits into from

Conversation

justbur
Copy link
Contributor

@justbur justbur commented Nov 18, 2015

Obviously a large change and deserves scrutiny, but everthing is working fine for me. The benefits are

  1. No longer need to hack evil-leader to get it to support multiple leader keys. Also no need for a minor mode to be active for leader keys to work
  2. Centralized control of spacemacs/set-keys and spacemacs/set-keys-for-mode
  3. Ability to use minor-mode bindings
  4. Distinguish maps from where they are bound. All of the major mode maps could be moved off of "m" for example very easily.
  5. describe-keymap can be used on each of the generated maps to easily inspect them, since they are all distinct and easily available.
  6. More complicated schemes become possible, such as having leader maps that span multiple minor and/or major modes. A lisp leader map perhaps
  7. Less code to maintain

"C-S-j" nil
"C-S-k" nil
"C-S-l" nil
"tH" nil ;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rogue comment. :-)

@TheBB
Copy link
Contributor

TheBB commented Nov 18, 2015

Nice work. I don't see any show stoppers. The diff is predictably mostly dull reading.

@justbur
Copy link
Contributor Author

justbur commented Nov 18, 2015

@TheBB fixed. thanks for going through it

(define-key state-map
(kbd dotspacemacs-major-mode-emacs-leader-key) major-mode-map))
(define-key state-map (kbd dotspacemacs-emacs-leader-key) root-map)))))
(defalias 'spacemacs/set-keys-for-mode 'spacemacs/set-keys-for-major-mode)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this alias ?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like spacemacs/set-keys-for-major-mode is used only once, consider defined directly the function with name spacemacs/set-keys-for-mode (renamed accordingly if we change it, see above comments).

@syl20bnr
Copy link
Owner

Excellent 💯

See my comments.
Also how do we set keys for a minor mode ? Is this the reason behind the defalias and the minor mode variant is missing for now ?

@syl20bnr
Copy link
Owner

Since this PR is huge we have to merge it as soon as possible, ideally we should try to address the review tomorrow so I can merge it during the evening.

I'm going to work on the move of evilification stuff, so you'll be able to rebase on this.

@syl20bnr
Copy link
Owner

I finished to move evilified-state files.

@justbur
Copy link
Contributor Author

justbur commented Nov 19, 2015

Also how do we set keys for a minor mode ? Is this the reason behind the defalias and the minor mode variant is missing for now ?

It was but I'm going to change it to be more explicit

Since this PR is huge we have to merge it as soon as possible, ideally we should try to address the review tomorrow so I can merge it during the evening.

I'm working on it now. Should be done soon

A couple of things :

  1. I'm going to bring back the evil-leader setup temporarily otherwise everyone who uses it to set keys in their personal config will have problems
  2. We might need to adjust the key bindings in some modes after this change. The issue is that the evil-leader map might have been shadowing some minor mode bindings, and since we are now using the global state maps (like evil-normal-state-map) these bindings might now take priority. Before you do this, be aware of this because there might be some reports like this (they are easy to fix though).

@StreakyCobra
Copy link
Contributor

I'm going to bring back the evil-leader setup temporarily otherwise everyone who uses it to set keys in their personal config will have problems

@justbur Instead on bringing back evil-leader just for this, can't you provide functions doing the same on top of your new code? It will allow to indicate its depreciation to users with a message and do the transition smoothly.

Edit: wording

@syl20bnr
Copy link
Owner

@StreakyCobra good idea, let's define our own transitional and minimalistic evil-leader package with the same API that redirects to bind-map. I know it is not as trivial as it sounds to emulate evil-leader but I don't see how we can better deal with this big refactoring.

@justbur
Copy link
Contributor Author

justbur commented Nov 19, 2015

@syl20bnr @StreakyCobra it should be perfectly fine for the two packages to coexist. If people want to use evil-leader for some reason, we shouldn't prevent that.

I'd say just issue a deprecation warning for a while and then remove support

@StreakyCobra
Copy link
Contributor

@justbur I said this because of the point 2) where you explained there could be problem between the two :-) If it's possible and easier to have both, let's go for this. The depreciation can still be advised.

@syl20bnr
Copy link
Owner

@justbur there won't be any leader key conflict bound to different sub-maps ?

@syl20bnr
Copy link
Owner

Since the evil-leader package is in core space and not user space I would go for an adapter to use only bind-map under the hood.

@justbur
Copy link
Contributor Author

justbur commented Nov 19, 2015

@justbur I said this because of the point 2) where you explained there could be problem between the two

The problem would be if we removed the configuration for evil-leader and people just use evil-leader/set-key. It wouldn't work because the leader key is no longer configured.

@justbur there won't be any leader key conflict bound to different sub-maps ?

Emacs deals with overlaying multiple active maps fine. It's a conflict if the same key sequence is bound to different commands (not prefixes) in different maps, emacs just uses the first one it finds so you have to know the priority rules for maps.

The only issue that may crop up is that we would now be using maps with different priority than the ones that evil-leader uses. The only place this would be a problem I think is if some minor mode uses evil-make-overriding-map to change the priority of its map with respect to evil's default map. I did this in evil-magit and I know dired does this, but there might be some other odd cases here or there. See my last commit for what to do.

I went through and renamed everything and added docstrings as requested. We still need to update the doc files, but I don't have time to do that right now.

@TheBB
Copy link
Contributor

TheBB commented Nov 19, 2015

But if we define a shim evil-leader/set-key that uses bind-map as a backend, it will work.

@justbur
Copy link
Contributor Author

justbur commented Nov 19, 2015

We could alias them for now
On Thu, Nov 19, 2015 at 9:09 AM Eivind Fonn notifications@github.com
wrote:

But if we define a shim evil-leader/set-key that uses bind-map as a
backend, it will work.


Reply to this email directly or view it on GitHub
#3860 (comment).

Set up to use bind-map instead of evil-leader for leader key
functionality.

Alias evil-leader funcs and remove package
Removes dependence on evil-leader centralizing control over the method
of key binding in core-keybindings.el
Adds useful help functions like describe-keymap.
Specifically need to be concerned with modes that make their maps
overriding.

 1. dired
 2. evil-magit
@justbur
Copy link
Contributor Author

justbur commented Nov 19, 2015

Ok they're aliased now.

By the way evil-lisp-state has evil-leader as a dependency

@TheBB
Copy link
Contributor

TheBB commented Nov 21, 2015

There are some merge conflicts now. Maybe you can address those? I would really like to have this merged today or tomorrow, before going on to the other PRs.

@justbur
Copy link
Contributor Author

justbur commented Nov 21, 2015

@TheBB would you mind doing it then? I'm traveling for most of the day and
probably won't have time.
On Sat, Nov 21, 2015 at 5:18 AM Eivind Fonn notifications@github.com
wrote:

There are some merge conflicts now. Maybe you can address those? I would
really like to have this merged today or tomorrow, before going on to the
other PRs.


Reply to this email directly or view it on GitHub
#3860 (comment).

@TheBB
Copy link
Contributor

TheBB commented Nov 21, 2015

Okay, done. 👍

Everything works here except the minor mode function. I can use it and it sets the keys in the correct map, but they don't become available when the minor mode is activated. We can fix that later though, since it's not used anywhere at the moment.

@justbur
Copy link
Contributor Author

justbur commented Nov 21, 2015

It won't work right away it requires a call to evil-normalize-keymaps which
doesn't happen right away
On Sat, Nov 21, 2015 at 10:35 AM Eivind Fonn notifications@github.com
wrote:

Okay, done. [image: 👍]

Everything works here except the minor mode function. I can use it and it
sets the keys in the correct map, but they don't become available when the
minor mode is activated. We can fix that later though, since it's not used
anywhere at the moment.


Reply to this email directly or view it on GitHub
#3860 (comment).

@TheBB
Copy link
Contributor

TheBB commented Nov 21, 2015

Oh okay. That works but I see now they end up under the major mode keys.

Anyway, we can deal with that later.

@justbur
Copy link
Contributor Author

justbur commented Nov 21, 2015

What do you mean under the major mode keys?
On Sat, Nov 21, 2015 at 10:47 AM Eivind Fonn notifications@github.com
wrote:

Oh okay. That works but I see now they end up under the major mode keys.

Anyway, we can deal with that later.


Reply to this email directly or view it on GitHub
#3860 (comment).

@justbur
Copy link
Contributor Author

justbur commented Nov 21, 2015

Oh I see SPC m. Yes that's where I put them but that can easily be changed.
On Sat, Nov 21, 2015 at 11:05 AM Justin Burkett justin@burkett.cc wrote:

What do you mean under the major mode keys?
On Sat, Nov 21, 2015 at 10:47 AM Eivind Fonn notifications@github.com
wrote:

Oh okay. That works but I see now they end up under the major mode keys.

Anyway, we can deal with that later.


Reply to this email directly or view it on GitHub
#3860 (comment).

@TheBB
Copy link
Contributor

TheBB commented Nov 21, 2015

Thanks, this is now merged. Brace yourselves. :-)

@syl20bnr
Copy link
Owner

For this kind of big changes I would like to be able to merge it myself. In this particular case I would have not cherry-picked commits, I would have preferred to merge without fast-forward using the GitHub button to have a merge commit in the history for easy revert if needed.

I still cannot review the now merged changes so I cannot comment anything for now. I hope to be able to do it this evening.

@TheBB
Copy link
Contributor

TheBB commented Nov 21, 2015

All right 👍

@TheBB TheBB mentioned this pull request Nov 22, 2015
@syl20bnr
Copy link
Owner

Amazing job guys !! 💜
I fixed evil-lisp state, I'll update the configuration when MELPA has processed it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants