Snipmate undo point breaks supertab completion results forward scrolling.

[ervandew]

Commit 73a7255 (Create undo point before expanding snippet in insert mode.) breaks supertab forward scrolling through the completion pop.

Removing the <c-g>u that was introduced to the mapping resolves the issue.

[garbas]

this was a merge of pull request[1] from msanders repo.
i'm not supertab user and as discussed in past[2] it was advised to map snipMate and supertab to different keys.

can you elaborate how "forward scrolling through the completion pop" works? how to reproduce this bug?
does bug that was fixed with unde point still exists with supertab? which version of supertab you are using?

[1] - msanders#17
[2] - #23

[ervandew]

this was a merge of pull request[1] from msanders repo.

I remember when this change had a short discussion where at least one user didn't agree with the addition, unfortunately I don't recall where that discussion took place and I didn't know the change affected supertab or I would have raised this issue at that time.

i'm not supertab user and as discussed in past[2] it was advised to map snipMate and supertab to different keys.

Yeah I generally agree with that advice, but unfortunately both plugins currently default to using tab and most users aren't going to get past the "it doesn't work" stage.

can you elaborate how "forward scrolling through the completion pop" works? how to reproduce this bug?

Sure, just start a new buffer with the contents:

Foo
FooBar
FooBarBaz
F

Then hit <tab>, while in insert mode, after the F on the last line, which will bring up the completion popup, then try hitting <tab> again and notice that nothing happens. Subsequent tabs should scroll through the results in the popup.

does bug that was fixed with unde point still exists with supertab?

I don't understand this question. I used the current vim-snipmate head at the time and did a bisect to find at what point vim-snipmate affected supertab's scrolling. I have my own branch of msanders/snipmate that works fine so I knew it must have been a relatively recent addition.

which version of supertab you are using?

git head (ervandew/supertab@80ec6539e4139a2e0281), but the undo point most likely affects a broad range, if not all, versions. I also tested w/ 0.51 from back in 2009 and the undo break affects that version as well.

[lightningdb]

I've got this issue, and at least one other person does too: ervandew/supertab#22

[lightningdb]

I forked and undid the breaking commit so I could use both plugins, but perhaps there is a way to change the mapping in my .vimrc?

I'm not entirely sure how to do this without clobbering all the things mapped to , but if there is a way, then a note in the documentation on how to do this would be good.

[nblock]

i can confirm the problem. happens here as well.

[lightningdb]

nblock: lightningdb/vim-snipmate has the breaking change reverted. As mentioned in my comment above, maybe there is a way to override that setting from a vimrc? (so that a fork or fix isn't needed)

[smlx]

I'm also seeing this issue.. it's very annoying, and would be nice to see fixed.

[lucapette]

I strongly agree with @garbas. I could image a lot of issues in the near future if we try to maintain compatibility between vim-snipmate and supertab. So, it would be a good idea to map the two plugins with different keys. I would like to close the issue too...

[ervandew]

I just want to throw out the fact that snipmate was compatible with supertab almost since its inception 2 and half years ago. It's only been a single 5 character change that has broken that compatibility (a change that taken on its own could be debated).

Despite the possibility of conflicts, I like that both supertab and snipmate are mapped to the same key since they both perform completions. So even if snipmate's default mapping where to change, it would be a shame that a user couldn't switch back to <tab> without breaking supertab.

[gadamiak]

Wow, it's been a year now with this issue open! Is this undoable or you really don't care?