Customize mode not evil

[quicknir]

Not too much more to say. I don't think it's a bug per se because I doubt this functionality was added in the first place. But customize should ideally start in vim/evil mode, not in emacs mode (if you have vim keybindings selected). If someone can point me to some code that reflects the canonical way of doing this for another mode (adding to the major mode hook?), I can prepare the PR myself.

[bmag]

1. use evil-set-initial-state and Evil will take care of the rest
2. don't use evilified-state-evilify-map or evilified-state-evilify because then you can't write in the text boxes (at least not easily)

[TheBB]

Indeed, it's the text input that has prevented us from doing this before.

[quicknir]

@bmag @TheBB Can you guys clarify the text entry issue? I clearly don't have the understanding you guys have, but what I can observe is that if I hit C-z, I don't have any problem writing in text input boxes. Vim's insert mode does the same thing as emacs. Can you give a quick example of something problematic?

[TheBB]

If you enter evilified state, there's no binding to go to insert state.

If you use normal state, sure you can do it. You lose all the customize bindings though, so you want to put them back. (SPC hdK custom-mode-map)

[quicknir]

I see, I was not distinguishing evilified and normal. I guess there are two solutions, I think either of these are better than the status quo, so we should pick one and then execute it:

1. Inject some extra bindings into the evilified state to make insertion and so on possible.
2. Use normal state, and simply rebind the shorcuts as we think appropriate. Within this we could go a couple of ways: we could keep the evilified approach of making n into C-n, and so on. Or we could bind things under the major mode leader.

Personally I think we should do 2. People who are using emacs are not affected by this anyway, so the goal is to give a better experience to vim users. As a vim user, the bottom line is that while customize is a bit weird, its ultimately a buffer where both motion and editing are possible, so I'd rather have normal mode. Some of the default bindings are also a bit unpleasant, notably customize takes over SPC and binds it to scroll up. It's much preferable (IMHO) to just keep using C-u for that, and be able to use SPC to switch windows. We really only need a few of the bindings anyway, like next widget and previous, many of the others have equivalents in normal mode or aren't that useful. We can even bind something useful like next widget to both C-n and , n for example (the conflict with paste ring or what not isn't too bad).

[quicknir]

@TheBB You wrote "ready for work", just to clarify: which of 1 or 2 (that I listed above) would you/syl/other maintainers expect? Either if executed well?

[TheBB]

Whatever works.

[JAremko]

Great idea 👍

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

[real-or-random]

I think this is still a valid issue.

[smile13241324]

@real-or-random I have just merged a commit to evilify Custom-mode, isn't this what this issue was requesting in the first place?
If you are looking for more evil bindings, please open a PR or an issue showing which bindings are missing for you.

[real-or-random]

Oh I see. The story behind this is that I was running into the issue described in #13970. At that time I was assuming customize mode does not work at all: I didn't really try with the keyboard. I only tried q which closed the window, so I concluded that this is not evil yet, and when looking for issues related to customize mode, I found this one and didn't see the recent commit.

So

• this issue here has indeed been fixed (but I added a nit comment your the commit 68debde#r42682553)
• Using the mouse in customize work only in insert state #13970 is only an issue when using the mouse (I edited the issue)