Closed Townk closed 12 years ago
Ah, I see. I'll have to look into that, the Enter / Space expansion is still a bit experimental.
do I get it right, to see this problem I need just our plugin + supertab?
I think so, but I honestly didn't had time to test it myself
I am experiencing a conflict between the two. checking out head on both breaks the end behavior in ruby. I was able to isolate it to the most recent commit for your repo, and the conflict was with vim-endwise. I did catch some weirdness with supertab as well, but it was less defined.
If I create a new file foo.rb and type def foo<cr>
, no end is created.
if I checkout the b63af10761e5b783aecd189847c73ca3202bb5fd
commit, the behavior is fixed.
I hope this helps.
@artm Hi -- I was the person to originally report the issue, so I thought I would clarify, since github seems to have stripped portions of my email posted above by Townk.
Thanks for looking into this and let me know if you cannot reproduce it and/or if you need additional details.
@glanotte:
workaround in your .vimrc
: let g:AutoCloseExpandEnterOn = ""
@thenoseman:
Thanks, it worked like a charm
@thenoseman:
Thanx! That worked for me too!
As far as I could check here this problem happens because of the popup menu being shown. We do have an option on AutoClose that lets you define a special behavior for certain keys when the popup menu is visible.
Using this allow you to tell AutoClose to issue a "
Here is what I use on my own .vimrc:
let g:AutoClosePumvisible = {"Esc": "
I'll add these maps as the default behavior so no one has to worry about this in the future.
It seems to me that supertab capability problem still appears. I've tried clean vim installation on openSUSE and on ubuntu with latest versions of supertab and autoclose. When you hit ESC on element in popup menu, this element actually will not appear. The text would be the same as you typed and vim would be in 'insert' mode instead of 'normal' mode.
I just receive this bug report by email and I don't want to loose track of it: