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

Using evil-leader on specific modes (in Emacs state) #16

Closed
oscarfv opened this issue Sep 17, 2013 · 5 comments
Closed

Using evil-leader on specific modes (in Emacs state) #16

oscarfv opened this issue Sep 17, 2013 · 5 comments

Comments

@oscarfv
Copy link

oscarfv commented Sep 17, 2013

Hello, one happy user here.

Some non-editing major modes that run in Emacs mode (magit, for instance) could put evil-leader to good use without requiring to punch non-normal-prefix. Thus, ",b" would work on magit as if it were in normal mode.

Something like

(add-hook 'magit-mode-hook (lambda () (local-set-key evil-leader/leader <?>))

My question is: what should <?> be for achieving what I want? I hope there is a trick with keymappings that achieves that.

BTW, this is somewhat related to #2

@cofi
Copy link
Owner

cofi commented Sep 17, 2013

I don't concur this is related to #2.

But on to the issue:
As workaround you could test this advice:

(defadvice evil-leader-mode (around maybe-no-non-normal-prefix activate)
  (let ((evil-leader/non-normal-prefix (if (member major-mode '(magit-mode))
                                           ""
                                         evil-leader/non-normal-prefix)))
    ad-do-it))

Adjust the mode list to the modes you don't want to be prefixed.

For the longterm, I think your idea is useful but I'm unsure about the way to tackle it:

  • Use a list like the one above to exclude major-modes from prefix treatment,

or the more flexible approach

  • allow major-mode specific prefixes (including none).

@oscarfv
Copy link
Author

oscarfv commented Sep 17, 2013

Michael Markert notifications@github.com writes:

I don't concur this is related to #2.

The reporter wanted to use the leader mechanism (without prefix) on all
buffers and your reason for deciding that that is not okay was:

"In theory you could customize the prefix to "" but I'd advise against
it as you can't type a , in a normal way anymore."

We can easily work-around that problem with

(evil-leader/set-key evil-leader/leader '(lambda () (insert evil-leader/leader))

Thus, if evil-leader/leader is \, pressing \\ would insert a
backslash. Furthermore, evil-leader could detect the binding for
\\ and reassign it to \\. I'm not sure that the order of keymap
creation, minor mode activation, hook calls, etc allows this, though.

This has some problems (the user might change evil-leader/leader
afterwards, or maybe he wants \\ to do something different...) but
evil-leader is so convenient that it is worth to (optionally) extend its
use to the maximum possible extend.

I guess that you'll say that all this is a good reason for me submitting
a pull request :-)

As for your suggested advice that addresses my question, it works. Thank
you.

For the longterm, I think your idea is useful but I'm unsure about the
way to tackle it:

  • Use a list like the one above to exclude major-modes from prefix treatment,

or the more flexible approach

  • allow major-mode specific prefixes (including none).

IMO a list of regexps is most practical. Magit, for instance, may create
multiple buffers with different major modes. The name of those major
modes are "magit-.*-mode". Explicitly enumerating all of them in a list
may be tiresome and require updates from time to time as magit evolves.
A regexp solves the problem nicely.

BTW, I don't think it is a good idea to disable the prefix on the
buffers where the leader is not applicable (i.e. normal mode.) We gain
nothing from ignoring C-evil-leader/leader where evil-leader/leader
is acceptable.

Thanks again for evil-leader and for solving my request.

cofi added a commit that referenced this issue Sep 20, 2013
Addresses issue #16.

Signed-off-by: Michael Markert <markert.michael@googlemail.com>
@cofi cofi closed this as completed Sep 20, 2013
@oscarfv
Copy link
Author

oscarfv commented Sep 21, 2013

Thansk @cofi for implementing evil-leader/no-prefix-mode-rx.

There is a small typo on the FAQ:

in the insert and emacs states which means you can’t type the char <leader> stands for (\ by default).

I think the opening parenthesis is misplaced:

in the insert and emacs states which means you can’t type the char <leader> (stands for \ by default).

OTOH, on the discussion above I suggested a list of regexps, not a single regexp. The reason is that a single regexp can quickly turn into something difficult to read. Compare

"magit-.*-mode\\|elfeed-mode\\|gnus-.*-mode"

with

(list "magit-.*-mode" "elfeed-mode" "gnus-.*-mode")

But this is a minor detail (and Emacs uses variables holding regexps on quite a few places.)

Thanks again.

@cofi
Copy link
Owner

cofi commented Sep 21, 2013

Re paren: Well, it was intended but I rephrased it now.

I changed it now to a list of regex but I'm not exactly with your reasoning there.

  1. It's easy to do so yourself (mapconcat #'identity '(put your regexp here) "\\|") and you are done)
  2. You can't use rx now.

@oscarfv
Copy link
Author

oscarfv commented Sep 21, 2013

Michael Markert notifications@github.com writes:

Re paren: Well it was intended but I rephrased it now.

Uh, sorry. I see that the original phrasing is idiomatic English indeed.

I changed it now to a list of regex but I'm not exactly with your reasoning there.

  1. It's easy to do so yourself (mapconcat #'identity '(put your regexp here) "\\|") and you are done)

Sure, but not everybody is so Elisp-savvy as us :-)

  1. You can't use rx now.

I wasn't aware of the existence of rx. After reading how it works on
EmacsWiki I'll say that I prefer to write regexps directly :-) But I
think that you can use it anyways:

(list (rx ...) (rx ...) ...)

Thanks for being so responsive (even on the cases where you are right!)

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

No branches or pull requests

2 participants