dealing with evil-mode

[Dickby]

I saw this package adds itselft to evil-emacs-state-modes.
I understand that is for preventing problems with the bindings.
while evil-mode adds vim like functionality to emacs, it doesn't deal with most third party packages.
For that reason evil-collection was created to add that vim like funcionality.
I guess most people that use evil-mode either use evil-collection or are used to deal with those problems themselves.
There are different strategies to better integrate packages to the evil workflow.
Some users might set emacs-state for special modes, some might use evil's motion-state,
others might just locally override evil-normal-state bindings.
Vundo enables evil-emacs-state by default, this might interfere with strategies that evil-mode users already developed.
evil-collection-vundo.el is part of evil-collection. that file for example sets evil-state back to normal-state and rebinds the keys to use "hjkl" for motions in vundo-mode.
I assume most evil users would like to have those bindings, if they are not using evil-collection they are likely going to try to remap the keys and have to first realize, that vundo sets the state to emacs-state (it took me a while to find that issue).
For that reason, i recommend not setting any evil specific things to try to make some bindings work in evil-mode.
Those bindings are not evilish anyways.
Or at least make the state change optional and mention it inside the readme file.
What do you think?
Thanks

[casouri]

Sure. I don't know evil very well so when someone sent a patch that supports evil I accepted it ;-) What is your suggested change? Could you describe it concretely or send a PR?

[ideasman42]

Note that I use evil-mode with vundo and don't experience any cursor issues, I'm not sure why.

[Dickby]

I would suggest, to either introduce a costumizable variable for enabling/disabling the evil-emacs-state change,
or don't set that evil-state at all and mention the evil-emacs-state solution aswell as the option to use evil-collection,
in the readme (in a section for evil users).
I'm not totally shure what's the best way.

[Dickby]

@ideasman42 which emacs version do you use? could you try it by starting emacs from the evil directory with make emacs from the command line,
to see if the reason is in your personal configuration?

[mentalisttraceur]

On the one hand, I personally think it's wrong design in principle for a couple of reasons to do this. I think it's also a good clue that undo-tree doesn't do this, and it has had over a decade of coexistence with Evil and a much larger user-base against which to discover which choice is wiser.

But on the other hand,

• even when vundo-mode is in the Emacs state list, if it's also in one of the other state lists (checked with motion, which makes the most sense, and with normal), that other vi-like state takes precedence (it's not great to be coupled to that order, which I don't know if that's even considered a part of the stable interface by Evil, but it means us users can just configure it instead of having to resort to monkeypatching with advice).

• I can see how it's maybe better UX in the common case. (Not for me, I just put it my undo tree in motion state and bind vi-style motion keys to the tree's motions. So "hjkl" in vundo mode would be mapped dor me instead of your "bnpf", and I'd figure out some intuitive conceptually parallel mapping to larger motions as I wanted to use them - like probably vi's "b" for back to prior branch since a branch is a larger unit of nodes just like a "word" in vi is a larger unit of characters. But many Evil users seem to want to have a bunch of their special buffers in the Emacs keybind paradigm for some reason, and maybe that's more common/representative.)