Raimondi / delimitMate

Vim plugin, provides insert mode auto-completion for quotes, parens, brackets, etc.
http://www.vim.org/scripts/script.php?script_id=2754
1.98k stars 117 forks source link

c23ef68 breaks delimitMate_expand_cr #202

Closed moll closed 9 years ago

moll commented 9 years ago

Hey,

I'm not yet sure why, but the c23ef68 commit breaks delimitMate_expand_cr for me. MacVim v7.4 with patchset 258.

Cheers

eloytoro commented 9 years ago

Its broken for me too with vim 7.4 None of the options work

moll commented 9 years ago

Now's probably a good time to add some tests to delimitMate. Manual testing like this sounds like a waste of everyone's time in 2015. ;-)

Raimondi commented 9 years ago

It works for me.

@eloytoro what do you mean by "none of the options work"?

@moll agreed, I need to add more tests because many cases are not covered by the current ones in the test dir.

Try this:

Also, paste the output of :DelimitMateTest so I can see if there is any relevant info.

noahfrederick commented 9 years ago

I am experiencing the same issue, where let g:delimitMate_expand_cr = 1 has no effect (i.e., acts like let g:delimitMate_expand_cr = 0) as of a week or two ago.

I narrowed down the problem with an incompatibility with tpope/vim-endwise, which also maps i_<CR>. However, there was no incompatibility before updating delimitMate a week or two ago—they worked fine together. I have not specifically verified that it was the above commit where things broke for me, but the timing is right.

noahfrederick commented 9 years ago

Upon further investigation, my issue is unrelated to commit c23ef68 and depends on the order in which the plugins are sourced. Sorry for the noise.

moll commented 9 years ago

I personally use Pathogen and let them be sourced as it sees fit (which should be alphabetical). Is there some order dependency now between Endwise and delimitMate that wasn't there before? I am using both, too.

noahfrederick commented 9 years ago

Is there some order dependency now between Endwise and delimitMate that wasn't there before?

I don't think so. It's necessary to source Endwise last (and always has been, as far as I know) because it preserves delimitMate's i_<CR> mapping and not vice versa. So I imagine you won't run into that particular problem loading them both with Pathogen.

moll commented 9 years ago

That's one crappy interdependency. Can it be fixed so the loading order is irrelevant?

Raimondi commented 9 years ago

@noahfrederick thanks for finding out it was an issue with loading order, that made it obvious to me where the problem was located.

In c23ef68 I delayed the call to s:setup() until the VimEnter event, with 254a89d I have restored the call to the original place. Let me know if that fixes the issue.

Raimondi commented 9 years ago

BTW, pasting the output of :DelimitMateTest would also have been helpful to show where the problem was since it would show that <CR> was remapped by another plugin.

noahfrederick commented 9 years ago

@Raimondi The root of the issue I was experiencing was that delimitMate won't create a map when a map already exists, so if it is loaded second, it does nothing. Endwise, on the other hand, tries to be clever and tacks it's map onto the end of an existing <Plug> map ending in CR (perhaps specifically for compatibility with delimitMate), so when it is loaded second, both plug-ins work together. The load order will always matter as long as delimitMate doesn't use the same trick that Endwise does. I imagine this won't be a problem for users loading plug-ins alphabetically.

Raimondi commented 9 years ago

The problem with endwise approach is that generally you can't properly restore mappings that way, there are cases that will break the mapping. You can just define the mappings yourself in your vimrc if you need to work with overlapping plugins.

delimitMate uses too many unreliable tricks already, so I don't want to add another just to save the user from defining a mapping in his/her vimrc.