emacs-evil/evil-collection

A set of keybindings for evil-mode

evil-collection's Issues

Consistency: helm, ivy

I guess it would make sense for those bindings to be consistent.
Spacemacs has done some work in the area.

dired: Search is broken

evil-search-next is not bound in dired since evil-dired binds n to dired-next-line.

Eval when evil-move-beyond-eol is nil

Would be great to have comments for:

771dfbe

08cb490

Ideally, I'd like to support evil-move-beyond-eol being nil (since that's the vim default), which means supporting the various lisp modes that eval expecting cursor to be after the last paren.

I'll close this and continue advising those eval functions if there's no comments in a week or two.

Rationale: Marking

The rationale has now some idea about marking.

It's not clear yet if we should ignore u or U to unmark, since most modes supporting marking do not support "undoing actions".

It's not clear either whether the marking bindings should be togglers and whether they should work on regions. I like the idea of regions though.

Error with emms

Hello,

I have just tried using evil-collection, with everything enabled, and get the following error backtrace when trying to start emacs:

Debugger entered--Lisp error: (void-variable emms-browser-mode-map) (list emms-browser-mode-map emms-playlist-mode-map) (let ((--dolist-tail-- (list emms-browser-mode-map emms-playlist-mode-map))) (while --dolist-tail-- (let ((map (car --dolist-tail--))) (evil-define-key* 'motion map "+" 'emms-volume-raise "=" 'emms-volume-raise "-" 'emms-volume-lower "u" 'emms-playlist-mode-undo) (setq --dolist-tail-- (cdr --dolist-tail--))))) evil-emms-setup() funcall(evil-emms-setup) (closure ((req . emms) (--dolist-tail--) (reqs emms) (m . emms) (mode . emms) (--dolist-tail--) t) nil (require (intern (concat "evil-" (symbol-name m)))) (funcall (intern (concat "evil-" (symbol-name m) "-setup"))))() eval-after-load-helper("/home/ucecesf/synced/emacs/emms-4.2/lisp/emms.el") run-hook-with-args(eval-after-load-helper "/home/ucecesf/synced/emacs/emms-4.2/lisp/emms.el") do-after-load-evaluation("/home/ucecesf/synced/emacs/emms-4.2/lisp/emms.el") load-with-code-conversion("/home/ucecesf/synced/emacs/emms-4.2/lisp/emms.el" "/home/ucecesf/synced/emacs/emms-4.2/lisp/emms.el" nil t) require(emms) eval-buffer(#<buffer *load*-332336> nil "/home/ucecesf/synced/emacs/emms-4.2/lisp/emms-browser.el" nil t) ; Reading at buffer position 10941 load-with-code-conversion("/home/ucecesf/synced/emacs/emms-4.2/lisp/emms-browser.el" "/home/ucecesf/synced/emacs/emms-4.2/lisp/emms-browser.el" nil t) require(emms-browser)

In my experience, emms frequently causes difficulties unfortunately.

I am using emacs snapshot for Debian, v27.0.50.

Hash-quote functions?

Should we hash-quote all functions in all bindings?

Join forces with Spacemacs

Spacemacs community is huge (apparently much bigger than I initially thought) and diverging too much from it could be a terrible move resulting in more fragmentation that we would ever dread.
On the upside, we would clearly benefit a lot from such a knowledge base and a community of this size.

This awareness was brought to me in the following discussion:
https://www.reddit.com/r/emacs/comments/7brlns/need_opinions_could_it_be_worthwhile_to_switch_to/dpld660/?utm_name=emacs.

As a result I've contacted Spacemacs maintainers to see what we can do about that:
syl20bnr/spacemacs#9850.

I've update the README with a link to Spacemacs' conventions (i.e. rationale):
https://github.com/syl20bnr/spacemacs/blob/master/doc/CONVENTIONS.org#key-bindings-conventions.

Evilify Macro

jojojames/evil-integrations#1 (comment)

(15) Evilify macros: Why not using the expansion of those macros? ;)
I think it's important to keep our bindings as readable as possible to anyone. Consider there might be newcommers from Vim who do not know Elisp.
Last but not least, the macro does the easy part, that is, the most trivial bindings. Those are usually a matter of copy-pasting and can be done within minutes. The hard part cannot be derived automatically.
So the "better than nothing" can also be done with explicit binding very quickly I think.

The evilify macro does quite a bit, it actually rebinds the pre-existing mode bindings up a waterfall style way.

Hand editing the mode bindings for even simple bindings might not be as simple as one would expect because of that.

Normalize the documentation header

Let's make it consistent. I like the following:

;;; evil-bookmarks.el --- Evil bindings for bookmarks. -*- lexical-binding: t -*-

Then

;; Author: James Nguyen <[email protected]>
;; Maintainer: James Nguyen <[email protected]>, Pierre Neidhardt <[email protected]>

I guess for now we can keep both our names as maintainers.
As for the author, first come first served.

• Does "emacs" makes sense as a keyword? Isn't it obvious this is Emacs?

• Isn't URL and HomePage redundant?

Key translations

jojojames/evil-integrations#1 (comment)
Ambrevar/evil-special-modes#4

(12) @noctuid made some points on my repo: Ambrevar/evil-special-modes#4
I think the most important point is that we should provide for key translations so that users of non-QWERTY key maps can adapt easily (e.g. Dvorak, Colemak). I think I've seen a key translation system somewhere before, maybe in Evil.

I was looking at the expansion of

(evil-add-hjkl-bindings ag-mode-map 'normal
    "gg" #'evil-goto-first-line
    "gr" #'recompile
    "gj" #'compilation-next-error
    "gk" #'compilation-previous-error
    "\C-j" #'compilation-next-error
    "\C-k" #'compilation-previous-error
    "0" #'evil-digit-argument-or-evil-beginning-of-line
    "n" #'evil-search-next
    "N" #'evil-search-previous)

(evil-define-key 'normal ag-mode-map "h"
  (lookup-key evil-motion-state-map "h")
  "j"
  (lookup-key evil-motion-state-map "j")
  "k"
  (lookup-key evil-motion-state-map "k")
  "l"
  (lookup-key evil-motion-state-map "l")
  ":"
  (lookup-key evil-motion-state-map ":")
  "gg"
  (function evil-goto-first-line)
  "gr"
  (function recompile)
  "gj"
  (function compilation-next-error)
  "gk"
  (function compilation-previous-error)
  "
"
  (function compilation-next-error)
  "�"
  (function compilation-previous-error)
  "0"
  (function evil-digit-argument-or-evil-beginning-of-line)
  "n"
  (function evil-search-next)
  "N"
  (function evil-search-previous))

lookup-key may be what we're looking for?

Rationale: Debugging

It'd be good to make some requests too. :)

I'd like to see realgud (especially the shortkey mode keymap) set up for evil.

I don't use realgud yet because I don't have bindings set up and setting it up just to set up bindings for the future is a little daunting.

It'd be great if anyone already had something for realgud. I think the DOOM config might have something for it...

Dired: handle dired-x

When you (require 'dired-x), a bunch of bindings is done on dired-mode-map.

These are bound based on dired-bind-{man,info}, which happens by default.

(define-key dired-mode-map "N" 'dired-man)
(define-key dired-mode-map "I" 'dired-info)

The following bindings are ran unconditionally:

(define-key dired-mode-map "\C-x\M-o" 'dired-omit-mode)
(define-key dired-mode-map "*O" 'dired-mark-omitted)
(define-key dired-mode-map "\M-(" 'dired-mark-sexp)
(define-key dired-mode-map "*(" 'dired-mark-sexp)
(define-key dired-mode-map "*." 'dired-mark-extension)
(define-key dired-mode-map "\M-!" 'dired-smart-shell-command)
(define-key dired-mode-map "\M-G" 'dired-goto-subdir)
(define-key dired-mode-map "F" 'dired-do-find-marked-files)
(define-key dired-mode-map "Y"  'dired-do-relsymlink)
(define-key dired-mode-map "%Y" 'dired-do-relsymlink-regexp)
(define-key dired-mode-map "V" 'dired-do-run-mail)

Rationale: Go To / Toggle / Switch To REPL?

I notice a lot of programming modes have a 'switch'/'start'/etc REPL command.

Would it be unreasonable to put it at something like 'gz'? That's what I've been using so far for it.

Can we make SPC to scroll down optional?

This might be a bit niche, but I actually use SPC as my leader key (I don't use spacemacs, however). If this is a bit too specific, I can got through and unbind in all relevant maps myself.

Rationale: Jump (go to definition) and display other-window

Several modes (occur, pdf, etc.) allow to jump in other window or to display in other window (that is, pop up buffer but don't move the cursor).

In many cases, RET should jump to definition, i.e. act just like gd.

Then what about S-RET to jump in other window, and M-RET to display in other window?

Also o or C-o have been used in some places I believe.

Init improvements

Following up with the comments in 21e9a7d:

We want:

• defcustoms that will tweak the list of loaded modes in the init function.
• Make the init process and config as straightforward as possible.

Issue:

• As of now, the defcustom has to be set before evil-collection is required. This can be confusing and should be documented.
• As of now, running the init function after modifying the defcustoms will have no effect. While this is fine once the setup has been worked out by the user, it's not convenient for experimentating.
• The init function is convoluted. Adding support for lambdas does not help.

To be honest I'm not completely satisfied with the current state of the init function: it's already convoluted. Isn't there a simpler approach that would make thinks both straighforward and flexible? I'll try to come up with one.

Request: company

Company is very popular, it should probably be a high priority.

I personally use Helm as completion menu so I have little need for company-specific bindings.

Keybinding Syntax

jojojames/evil-integrations#1 (comment)

(14) This is a nit, really, but what about the key binding syntax? I see you use vectors and strings of escape control sequences like "\C-c\C-c". I used to do that, but then some sequence cannot be represented easily, like .
I'm now using the following convention: write them like C-h c displays them. It's better for clarity I think, and we want any user to be able to read our bindings. Motto: be as transparent as possible.

Without modifier not special keys, use a simple string, e.g. "gd".

Anything else in (kbd ...). Use the <bracket> notation for special keys.

Works for me. We can take care of normalizing this stuff after we've gotten everything into one repo.

Melpa

@Ambrevar Lets try and move forward with Melpa so that it's easier to obtain evil-collection.

Here's a list of issues tagged with Melpa already. I am splitting it up by what I don't see as required and what is probably required.

Required
Normalize the documentation header - #12
Documentation: use "state", not "mode" - #13
Documentation: Review readme.org - #14
Customizable initial/primary state - #21

Not Required
Keybinding Syntax - #8
Rationale: Sorting vs. Filtering - #20
image-mode and pdf-tools conflict - #23
Rationale: Marking - #19

Some of the required are already done and are left as a reminder. The biggest one seems to be #21.

In not required, I don't want rationale discussions to block pushing to melpa and image-mode/pdf-mode also doesn't seem to be too important to block.

#8, keybinding syntax, I see it the same way I see evilify macro. We want to move in one direction but the current stuff is fine as it is too, so it shouldn't be a blocker.

Let me know if you disagree with any points. I'm trying to avoid spinning wheels here and leaving this repo "melpa-less" for months. I know quite a few people that don't like to vendor / use git submodules and would prefer going through the package archives.

Key for refresh/redisplay (C-l/gr/etc)

jojojames/evil-integrations#1 (comment)

(5) While C-l makes sense for refresh/redisplay because of terminals, I don't know if refreshing/redisplaying should be bound such a short binding, it's not something we always want to do, is it?
For now we have gr. r is used for other things.
It's a good suggestion though, I will include it to the rationale.

gr works for me and seems fairly standard among the other evil packages.

Clean up byte-compiler's warnings

Following up on #22.

We want to have clean code and clean byte-compilation, i.e. no warnings.

As of now, some defuns are wrapped in with-no-warnings blocks. This has several downsides:

• It silences possible valuable warnings inside the defuns.

• The warnings are spurious: we should not add kludges around correct code. Code quality is more important than the opinion of an automated linter.

• It's not pretty and defuns are not top-level anymore.

Documentation: Review readme.org

At first glance, there is still a mention of "evil-special-modes".

Rationale: g? for Help?

Would it make sense to just push the help keys (whatever would land on '?' normally) to 'g?'?

That way there's a guarantee '?' never gets replaced (which I'd suggest is almost always useful).

Support evil-search-module set to evil-search

Here's a (perhaps a bit unclear) similiar issue opened and resolved in evil-magit: emacs-evil/evil-magit#33

tl;dr, when evil-search-module is set to evil-search (either before evil loads or with custom), different search commands are used, namely evil-ex-search* instead of evil-search*.

Request: Gnus

Because:

• It's needed for debbugs which we support.
• It's popular.

I will probably not do it soon since:

• I don't use it.
• It's huge.

Use `evil-set-initial-state` whenever possible

In your "kickstart" file, you've written

(setq evil-motion-state-modes
(delete 'ag-mode evil-motion-state-modes)))

I haven't tried but can't we use evil-set-initial-state?

Also what is ag-mode and why not being in motion state?

Naming

evil-integration-plus
evil-integrations
evil-collection
evil-binding-collection
evil-binding
evil-bindings

I am going with evil-collection for now but any of the above would work with me.

Make company-tng-configure-default optional

This led to some unexpected behavior for me, and I strongly think it should be set according to some option that defaults to nil. This seems like a "completion style" setting rather than a "evil integration" one.

Best effort for helm

Hello, trying this out. The evil-minibuffer stuff is really fantastic, I love being able to use modes when issuing compile commands. The only downside is that helm (which I use in the minibuffer, this is the default in spacemacs), ends up looking funny. I attached a screenshot. Basically the cursor both appears at the top of the helm buffer (where I normally type), but also at the very bottom. Some of the faces applied by spacemacs (changing the color and cursor style between normal and insert) appear at the top, some at the bottom. When you are in visual mode, the highlighted text appears at the bottom. Etc.

My understanding is that much of this is probably not fixable, due to fundamental minibuffer limitations. Related link: https://emacs.stackexchange.com/questions/17058/change-cursor-type-in-helm-header-line#17097.

I open this issue as a place where we can try to determine what the best possible behavior is for helm, and then restrict things to maximize benefit. For example, if visual mode can't be made to display properly, let's block access to it. Etc.

If it helps, I'm using spacemacs and thus the default helm setup in spacemacs.

image-mode and pdf-tools conflict

Depending on the load order, one mode takes precedence over the other which makes the latter unusable.

This might have to do with an inheritance problem.
Bug was reported upstream: politza/pdf-tools#324

Conflict between company-tng and company-preview-frontend

I use company-eshell-autosuggest which uses company-preview-frontend in Eshell to display commandline suggestions "à-la fish-shell".

TAB is normally used to confirm the suggestion. It is bound to company-complete-common.

With evil-collection, we enable company-tng through company-tng-configure-default which rebinds TAB and thus makes it impossible to confirm suggestions in Eshell.

This could be considered an upstream issue but maybe some of you know better. Any opinion on this?

Remove package-lint workaround on C-c <tab>

Use conventional syntax for C-c <tab> once purcell/package-lint#96 is resolved.

[Question] Is evil-make-overriding-map purposely avoided?

Evil-integration does this to some extent, and it seems like the right approach as it avoids re-defining default keys that you want to stay the same, while you can override keys relevant to evil. This might also make some of the code neater and easier to follow IMO.

Join forces with evil-mode organization?

The evil-mode organization already has a few evil-mode compatibility packages, and personally I think it'd make sense to join forces with them. Not sure how feasible it'd be though.

Rationale: Sorting vs. Filtering

Filtering (a.k.a. searching / narrowing) is an action that is common to many modes.
Sorting less so however.

It seems that many modes in Emacs state use "s" or "S" for sorting.
If we use the same in Evil states, then what key should we reserve for filtering?

Filtering bindings are inconsistent in Emacs state. We should not override / unless the new binding completely supersedes the functionality of evil-search-forward.

"open" bindings: go/gO?

Shall we replace the current "gd"/"gD" in the "open" section of the rationale with "go"/"gO"?

I tend to say: yes.

Initial groundwork

jojojames/evil-integrations#1 (comment)

(13) Setup: to get started, we need to lay down some ground work on how we setup the bindings.
This is how I did it:

;; main file
(defun evil-special-modes-init ()
  (interactive)
  (with-eval-after-load 'calendar   (require 'evil-calendar) (evil-calendar-set-keys))
	;;...
	)

;; mode-specific file
(defun evil-calendar-set-keys ()
  (evil-define-key 'motion calendar-mode-map
    "h" 'calendar-backward-day
		;;...
		))

So it's very similar to your evil-integrations.el except it is wrapped in a function call, as per Emacs packaging standard (only requiring a package should not modify Emacs behaviour).

What do you think?

Looks good to me.

Lets use this thread for other groundwork topics that may come up.

SPC as a special key

Copying last comment on this topic.

jojojames/evil-integrations#1 (comment)

(1) Redundant command: yes but which one? If it's only for SPC, why not. In most cases, SPC scrolls-up (@auwsmit: C-u scrolls half a page down), like C-f. The main difference is that in documentation modes like Info mode, SPC goes to the next node when it reaches the botton, while C-f (or Emacs' C-v) does not.

IIRC SPC seems to do something else for quite a few modes (magit?, edebug, dired maybe). I remember hitting the SPC binding a lot.

Binding (kbd "<tab>") in outline-minor-mode overrides org-cycle

I'd argue org-cycle is way more useful when you're actually in org-mode.

Term: Line/Char gets out of sync with insert state

Not sure how to exactly reproduce but the behavior was a little confusing.

It seems line and char mode gets swapped in and out. There's a way to get it in a state where you're in insert state and line state at the same time.

Documentation: use "state", not "mode"

Evil uses "state" for normal, insert, motion, etc.
This is to avoid confusion with the term "mode" which has a completely different meaning in Emacs.

Let's review the comments and the documentation to make sure there is no confabulation between "state" and "mode".
Non-Evil bindings should be referred to as "Emacs state bindings".

Man-quit removed in emacs 26

Just a heads up. Was removed in this commit: emacs-mirror/emacs@506a97a

Customizable initial/primary state

I prefer to never actually enter motion state and only use the keymap for actual motions.

Modes that need to be merged

jojojames/evil-integrations#1 (comment)

ansi-term / term
help
package-menu
profiler

@Ambrevar I think I added the ones from my end, what's left are modes that probably won't go in (like org and the packages that would probably require some merging.)

Like a nice intermediary step is for me to push ^ those above packages and you can just modify it as you like after?

autoload cookie

I think we should have only one autoload: evil-collection-init.
I'll remove the others.

Fully replace evil-integration

From emacs-evil/evil#992:

I'd like to think of evil-collection as serving as an alternative evil-integration.el here, so the all or nothing approach should be fine.

Currently, evil-collection is mainly focused on keybindings and is not an alternative to evil-integration. I'm not suggesting doing any opinionated configuration by default, only adding "fixes" that it's unlikely anyone would object to (e.g. advising show-paren-function to make show-paren-mode work correctly in normal state, adding evil command properties such as :repeat, :type, :keep-visual, and :suppress-operator, etc.). Anything considered potentially intrusive could be optional. Unfortunately, since evil-integration is all or nothing and will stay that way, its useful, non-intrusive functionality needs to be replicated in another package for users who want to sanely only use those parts of evil-integration. Maybe evil-collection is not the suitable place to do this, but I'm interested to hear your thoughts.

Evil equivalent for M-, (e.g. xref-pop-marker-stack)

jojojames/evil-integrations#1 (comment)

(3) So M-, is xref-pop-marker-stack and it's available in Evil. M-. is xref-find-definitions which is available in insert state, but in normal state, it's evil-repeat-pop-next.
Either way, this is an Evil's problem, I don't think it belongs to us to solve this.
This is how gd is used in my current bindings:

evil-calendar.el:65:    "gd" 'calendar-goto-date ; "gd" in evil-org-agenda, "gd" in Emacs.
evil-info.el:53:    "gd" 'Info-goto-node
evil-man.el:47:    "gd" 'Man-goto-section
evil-profiler.el:57:    "gd" 'profiler-report-find-entry

In those cases, the xref commands don't apply, so there is no problem. '' or C-o will do what you want.

I think we want a keybind to represent a pop from definition if we're going to use gd for go to definition. If some modes don't have a need for a pop definition, that's fine, but we'd still need one for modes that use it (almost all the programming modes). I don't think " or C-o suffices because they fulfill a different use case.

A quick scenario where you'd need a pop definition key is.

1. Go To Definition on symbol
2. Use a jump of some kind (G gg or something else)

" or C-o will go to the last location you were
M-, (Emacs) would bring you to the place where you called Go To Definition

Re: Evil

Yes, I think Evil should have an option to not override M-..

consider following unimpaired's foot steps for [ and ]

unimpaired is an extremely popular package among vimmers, and one of the most prominent keybindings is using [ and ] for navigation.

however, it's just a prefix key. for example, [q and ]q are used to navigate between the change list. this affects anything in emacs that derives from compilation-mode.

the current guideline binds an action [ and ] alone for many modes, making it quite tedious to undo it.

Add tags to the GitHub repo

That can help github users finding evil bindings and emacs packages.
I suggest "emacs", "evil" and "bindings".

Display Evil bindings cleanly in describe-mode

C-h m (describe-mode) should only display the Evil bindings when the current state is an Evil state.
As of now, it display all the original Emacs bindings with a

(that binding is currently shadowed by another mode)

line and the Evil bindings underneath. It's an overload of imformation.

Maybe we should look towards which-key.