how to cancel some parts of evil-integration?

[introom]

for this part in evil-integration:

(eval-after-load 'dired
'(progn
;; use the standard Dired bindings as a base
(defvar dired-mode-map)
(evil-make-overriding-map dired-mode-map 'normal)
(evil-add-hjkl-bindings dired-mode-map 'normal
"J" 'dired-goto-file ; "j"
"K" 'dired-do-kill-lines ; "k"
"r" 'dired-do-redisplay ; "l"
;; ":d", ":v", ":s", ":e"
";" (lookup-key dired-mode-map ":"))))

How to disable this part os (eval-after-load)?

[wasamasa]

You don't. Once code has been scheduled with eval-after-load to be loaded after dired, it becomes part of after-load-alist. Removing a value from it is about as tricky as removing a hook made with an anonymous function or rather, worse because it's about byte-compiled code.

I just wouldn't worry about this at all because the above only applies to dired in normal state. You don't want to use dired in that state anyway and instead customize it to use Emacs state instead.

[Alexander-Shukaev]

To be honest, I always wanted a feature request to disable default evil-maps, evil-integration, and evil-search. Those packages are very intrusive and for me, personally, only interfere for the most part. I would either turn them into big functions or many small functions which could of course be invoked by default when Evil is loaded, but I would also provide variables which would disable default invocations of these functions. Right now, I have to employ the following hack:

(eval-and-compile
  (unless (fboundp 'evil-update-insert-state-bindings)
    (fset 'evil-update-insert-state-bindings #'ignore))
  (with-eval-after-load 'evil-vars
    (dolist (feature '(evil-search
                       evil-maps
                       evil-integration))
      (add-to-list 'features feature))))

[Alexander-Shukaev]

In fact, I believe the future of Evil is clear separation of the framework and Vim defaults. I'm only interested in a framework and not in Vim defaults because I build my defaults on top of the framework. Forceful injection of these defaults makes my life more difficult within this goal.

[introom]

@Alexander-Shukaev You said what exactly are on my mind!

[wasamasa]

@Alexander-Shukaev Basic integration of Emacs packages is one thing, using Evil as framework for something else than Vim-style editing is another. If you have an idea how to make the integration bits easy to disable without introducing dozens of customizables, I'd be interested in it.

[Alexander-Shukaev]

I mean I'm still using it in a Vim-style editing if you mean modal text-editing. That's why I do use Evil in the first place. It's just that I have completely different mapping layout in all modes, tons of additional advanced operators and commands of my own implemented based on Evil as a framework. The reality is that I created my own package on top of Evil that depends on it and wraps it properly.

I guess architecturally, the best for Evil would be to split it into two packages.

• One infrastructure library that allows anyone to develop cool stuff: new operators, commands, modes, etc. with help of it. Just think about it, right now everyone who creates packages based on Evil, writes (require 'evil), what in turn silently installs some hooks, eval-after-loads, injects key bindings in some core keymaps. When I found this out, my reaction was like "WTF?". This is indeed bad design. I'm not blaming, Evil is a great package with a lot of effort put into it and I'm very grateful to every single contributor who made it happen, however, it's time to move forward. Its Lisp interfaces to define Vim-like behavior are already marvelously designed, though this is exactly what confuses me: how can such a well-designed framework be intermixed with such badly designed integration boilerplates.
• And another "official" package using that provides Vim's default key bindings, search capabilities, and this intrusive integration along with tons of configuration variables which are there already anyway. At the same time, the infrastructure library will be very clean, less bugs, better designed, less spaghetti code that assumes Evil is a huge blob of all this functionality at once. I think Evil as a framework has matured enough to deserve a repository of its own and be a general framework library for development of Vim-like features, while Vim defaults is just another small library (in its own repository) using the framework and is totally optional to install.

[TheBB]

I'm fine with introducing a single option to disable evil-integration altogether. I don't think we need to go further than that. People who want a modal framework to implement their own editing model are probably better served by a package like modalka. I'm not convinced we need to reinvent the wheel here.