Closed jnicklas closed 11 years ago
Sounds like another plugin you're using remaps the ENTER key in a way that prevents lusty-juggler from restoring it correctly. In a fresh Vim, before running lusty-juggler, run :map <ENTER> to get a better idea where that mapping is coming from.
There is an unimplemented TODO in Vim 7.3 and below:
maparg() doesn't return the flags, such as <buffer>, <script>, <silent>. These are needed to save and restore a mapping Also: the rhs string is not always correct. (Hari Krishna Dara, 2009 Sept 29)
What that is saying is that this is a bug in Vim. So I'll leave this issue open for now, but I hold no hope of fixing it on my end, alas.
I've actually remapped the enter key myself (to insert blank newlines). Can I change the mapping somehow to prevent this from occuring? Sorry my vimscript-fu is not strong.
Hmm. What does the mapping definition look like in your .vimrc?
It looks like this:
" remap enter/shift-enter to insert blank lines
map <S-Enter> O<Esc>
map <CR> o<Esc>
If I throw those mappings into my .vimrc, they're restored correctly after using lusty-juggler. So I bet there's still something else going on. What is the output from running this, in a fresh Vim and then after running lusty-juggler?
:verbose map <CR>
I'm having the same issues but I get no mappings shown unless I run :imap <Enter>
.
With that I get: <CR> & <CR><Plug>DiscretionaryEnd<C-R>=<SNR>35_SelectCompletion(0)<CR>
What do you get from running this?
:verbose imap <CR>
i <CR> & <CR><Plug>DiscretionaryEnd<C-R>=<SNR>35_SelectCompletion(0)<CR>
Last set from ~/.config/vim/bundle/supertab/plugin/supertab.vim
I'm guessing this means supertab is the culprit? Note, I only get this with a new file (with no name yet)
Supertab is the culprit in that it's what is mapping <CR> -- but the real culprit is Vim, since it provides no way to programmatically restore this kind of mapping.
You may be able to workaround the problem by setting this in your .vimrc:
let g:SuperTabCrMapping = 0
Thanks. That seems to have done the trick.
This should be fixed now thanks to https://github.com/sjbach/lusty/pull/32. You'll need to be running a recent version of Vim 7.3+ -- anything >= patchlevel 32.
Not sure if this helps, but on MacVim this issue still appears. Conflict with EndWise.vim
MacVim version is VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Aug 15 2010 22:03:01)
Is this a high enough version for the fix to take hold?
Surely you can configure lusty to use another key other than <CR>?
Hi, I can't speak to whether your version of MacVim has the patch, but since the problem still appears for you, probably not. The patch version should show beneath the line you printed, e.g.:
$ vim --version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Apr 23 2011 18:29:08)
Included patches: 1-162
...
To be clear, this isn't a bug in LustyJuggler that causes it to interacts poorly with e.g. EndWise; it's a bug in Vim. You have access to the LustyJuggler source, so if you'd like, you can change the <CR> mapping locally.
Hi, I'm having this same problem. I'm using a new version of MacVim:
$ vim --version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Jul 13 2011 10:13:57)
MacOS X (unix) version
Included patches: 1-237
As with jyn, the conflict appears to be with EndWise (removing EndWise fixes the problem). I'm using Vundle to manage my Vim plugins, so I should have the most recent version from github.
Is there a way to use both plugins?
Also, I've been playing with FuzzyFinder and Command-t, and for my needs, LustyExplorer is a much better choice. It does just want I want. Thanks for making it available with LustyJuggler (which I also really like).
This is fixed in MacVim 7.4 - Snapshot 70 - OS X 10.8.
Then I'll mark as closed. :-)
After triggering lusty juggler, pressing enter in insert mode will insert the string "DiscretionaryEnd" instead of a new line. This time I'm using the latest version off GitHub. ;(