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

holy-mode: Assume we are always in emacs state #3497

Closed
wants to merge 2 commits into from
Closed

holy-mode: Assume we are always in emacs state #3497

wants to merge 2 commits into from

Conversation

justbur
Copy link
Contributor

@justbur justbur commented Oct 21, 2015

There's some confusion about holy-mode, because users are accidentally
getting into another evil state and don't know what to do. The
assumption should be that if holy mode is enabled we are always in
emacs state, so we don't provide any easy means of getting out of it.
#3495
#3473
#3453

@syl20bnr
Copy link
Owner

This PR removes too much stuff. We only need to not override the ESC key. Being able to switch editing style dynamically is a feature that cannot be removed, if there are bugs we have to fix them.

@justbur
Copy link
Contributor Author

justbur commented Oct 21, 2015

You can switch editing styles dynamically with this. evil-buffer-regexps overrides all of the mode specific stuff, so it's not necessary to change those.

@syl20bnr
Copy link
Owner

Perfect 👍 You should make several commits then, in its current state this commit tells the why but not the what and how (which are more important to me, for the why just use issue ids with Fixes). I would prefer one commit for the ESC key and another one for the great simplification.

@justbur
Copy link
Contributor Author

justbur commented Oct 21, 2015

ok, I can do that. No problem

@justbur
Copy link
Contributor Author

justbur commented Oct 21, 2015

@syl20bnr It's split into two commits

@justbur
Copy link
Contributor Author

justbur commented Oct 21, 2015

On second thought maybe there should be a variable that allows the old behavior too

The variable `evil-buffer-regexps` overrides setting the initial evil
state based on mode, so all we do now is to set all buffers' initial
states to emacs using this variable. This avoids having to manage the
mode-specific state variables in evil.
We should not assume that users of holy mode are aware of evil and
normal state. Users were accidentally escaping into normal state with
ESC under the old implementation and didn't know how to return given
that they assumed they were only using emacs key bindings.

Fixes #3495, #3473 and #3453.

Introduce a new variable `holy-mode-allow-esc-to-normal-state` to allow
for the old behavior if users want to set this explicitly.
@syl20bnr
Copy link
Owner

The old behavior is hybrid no ? I have to look at those evilified state in hybrid state, I know we have a PR you submitted but maybe we just need a global toggle for evilification instead ?

@justbur
Copy link
Contributor Author

justbur commented Oct 21, 2015

No not really. The old behavior was to always start in emacs state, allow
users to escape to normal state, and override evil-insert-state. This turns
the last two off by default.
On Wed, Oct 21, 2015 at 4:24 PM Sylvain Benner notifications@github.com
wrote:

The old behavior is hybrid no ? I have to look at those evilified state in
hybrid state, I know we have a PR you submitted but maybe we just need a
global toggle for evilification instead ?


Reply to this email directly or view it on GitHub
#3497 (comment).

@syl20bnr
Copy link
Owner

If we can toggle off the evilification, hybrid looks like the old behaviour to me. And I like the fact that having ESC to switch to normal state is an hybrid thing.

@syl20bnr
Copy link
Owner

Ah there is the default state too. All these can be hybrid options. Actually should be hybrid options from the beginning.
At start we had not the hybrid style, now we have it we can make Emacs style as authentic as possible and put the options for hybrid behaviour in hybrid style.

@justbur
Copy link
Contributor Author

justbur commented Oct 22, 2015

At start we had not the hybrid style, now we have it we can make Emacs style as authentic as possible and put the options for hybrid behaviour in hybrid style.

I think it shouldn't be that hard to have a mode that disables evil entirely and makes the right adjustments for the mode-line, helm, etc. Is that what you mean by "as authentic as possible"?

Also there's another distinction between hybrid and emacs that's relevant to these issues. The reason these issues came up is because some people want to use ESC as a meta key, which is only possible with evil on in emacs state. Since hybrid uses a variation of insert state, this could be tricky to disable there.

@syl20bnr
Copy link
Owner

I was not very clear sorry.
I mean ESC to go to normal state is an hybrid thing which is already covered by hybrid-mode right now. The toggles are for:

  1. evilification
  2. default state
    Which only purpose is to fine tune the hybrid mode because in the end they are hybrid behaviors (now we have a true hybrid mode we can make emacs style as authentic as possible).

@syl20bnr
Copy link
Owner

Hybrid without normal state is not hybrid in my opinion so it makes little sense to remove ESC.

@nixmaniack
Copy link
Contributor

I would prefer the current hybrid left untouched. Yes, hybrid without normal mode is almost emacs state then. I even prefer buffers be opned in normal state even if I'm using hybrid, only when I enter insert state I should have all keys as emacs way for editing text, but for getting out of that state let it be ESC.

@syl20bnr
Copy link
Owner

Hybrid will be left untouched, those would be options to alter it, default values will setup the hybrid as it is right now.

@justbur
Copy link
Contributor Author

justbur commented Dec 14, 2015

Closing in favor of #3514

@justbur justbur closed this Dec 14, 2015
@justbur justbur deleted the holy-mode-2 branch January 30, 2016 17:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants