c23ef68 breaks delimitMate_expand_cr

[moll]

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]

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

[moll]

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]

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:

• cd into delimitMate's repo.
• run vim with vim -N -u basic_vimrc and check if you can reproduce the issue.
• If you can, paste here the contents of basic_vimrc; if not, add whatever configuration you have in your vimrc until you can reproduce it then paste those lines here. Add the lines on by one to prevent adding noise.

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

[noahfrederick]

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]

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]

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]

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]

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

[Raimondi]

@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]

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]

@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]

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.