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

Weird indentation effect when using evil-escape-key-sequence? #69

Open
zzantares opened this issue Jun 29, 2016 · 9 comments
Open

Weird indentation effect when using evil-escape-key-sequence? #69

zzantares opened this issue Jun 29, 2016 · 9 comments

Comments

@zzantares
Copy link

Hi, I'm having a little annoyance when using the evil-escape-key-sequence, basically when I do kj the indentation on the current line is modified. In the following animation I just want to add the close parenthesis ) in it's own line but keep it currently indented, so I just do RET and the ) gets correctly indented but as soon as I escape kj the ) moves out.

evil-escape

In the animation I do a second test but now pressing ESC and you can see it works fine without moving out the ), so it's only happening when using the key sequence.

Is there any magic setting I could use to avoid this effect?

Thanks

@zzantares
Copy link
Author

Do you have any suspicion of why is this happening @syl20bnr? I could try to look in to this but I don't where or what to search in the code.

Thanks.

@NateEag
Copy link

NateEag commented Oct 20, 2016

This happens because of the temporary insertion of the first letter of the escape sequence.

Some modes automatically indent code whenever you insert a character, and aggressive-indent-mode will let you get that behavior even in modes that don't.

I think you're probably dealing with one of those.

@zzantares
Copy link
Author

Thanks @NateEag so the problem is in the mode itself? I'll look in to that.

Thanks.

@NateEag
Copy link

NateEag commented Oct 21, 2016

@zzantares That's my belief, anyway. I have not actually tested your scenario myself.

However, the insert-first-keystroke-then-delete-it-on-second-one behavior has been causing me similar frustrations with my hacked version of aggressive-fill-mode.

My unpolished changes to aggressive-fill-mode make it fill after every character insertion.

Thus, when the first letter of my escape sequence gets inserted, it triggers a fill, which happens with the character in place.

On the next keystroke, the j is erased, which does not trigger a fill, and thus leaves my paragraph filled slightly wrong.

It also bites me if I escape after entering a blank line below a paragraph. The temporary character makes fill-paragraph see the line as not blank, then filling is triggered, so the j is moved up a line, then deleted, effectively erasing the blank line I just entered.

That's not really related to this issue - just wanted to explain the reasons behind my diagnosis. Your issue sounds very similar to the ones I've been having, so I assume it's the same cause.

I don't have a good solution for either case at the moment, just this analysis.

@NateEag
Copy link

NateEag commented Nov 4, 2016

addendum - I realized today that the paragraph removal I was seeing was due to a mistake I made while trying to eliminate the first problem I described. I thought I'd reverted the bad change, but apparently it stuck around somehow.

The above is probably still useful in understanding the behavior described in this issue, but the second behavior was not something that would have been reproducible outside my personal config.

@syl20bnr
Copy link
Owner

syl20bnr commented Nov 4, 2016

We may be able to fix this by temporarily inhibiting minor modes that
auto-intend things on insertion.

If you can provide a quick repro step I should be able to identify the
minor mode and provide a fix.

Le vendredi 4 novembre 2016, Nate Eagleson [email protected] a
écrit :

addendum - I realized today that the paragraph removal I was seeing was
due to a mistake I made while trying to eliminate the first problem I
described. I thought I'd reverted the bad change, but apparently it stuck
around somehow.

The above is probably still useful in understanding the behavior described
in this issue, but the second behavior was not something that would have
been reproducible outside my personal config.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#69 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABL5kdJ9xvU3f6whDTsu03Aop0uh7AHPks5q60WAgaJpZM4JBqIj
.

-syl20bnr-

@zzantares
Copy link
Author

zzantares commented Nov 6, 2016

Thanks @syl20bnr, here is what I did to reproduce the issue outside of my own emacs:

  • In a clean emacs (tested on 24.5 and 25.1) just install evil and evil-escape, eval this settings:
(evil-mode 1)
(evil-escape-mode 1)
(setq-default evil-escape-key-sequence "kj")
(setq-default evil-escape-delay 0.3)
(global-set-key (kbd "<escape>") 'evil-escape)
  • Edit a .py or a .rb file and insert something()
  • Put the cursor between the parenthesis and insert RET (so closing parenthesis ) should now be in its own line)
  • Escape to normal-mode using the escape-key-sequence defined (kj in this case), the closing parenthesis will move.

If you repeat the steps but escaping with ESC the closing parenthesis does not move, this is the preferred behavior.

Thanks!

@Linuus
Copy link

Linuus commented Mar 4, 2019

Do we have some kind of workaround for this issue?

@zzantares
Copy link
Author

zzantares commented Mar 4, 2019

For the record, I no longer use evil-escape, I've accustomed my self to use C-[, my Ctrl key is my caps lock and the right pinky is very near the [ so it feels very natural. Needless to say that the behavior described is no longer an issue for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants