# Vim LaTeX Suite interferes with UltiSnips <C-j> <C-k> bindings

Bug #944215 reported by Chris Lasher
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Committed
Low
Unassigned

### Bug Description

Vim LaTeX suite (vim-latex) (http://vim-latex.sourceforge.net/) provides handy utilities for working with LaTeX documents. Unfortunately when it is installed as a plugin along with UltiSnips, it completely ruins the mappings of <C-j> (Control + J) and <C-k> (Control + K) such that the user can no longer jump forward and backward in a snippet. Curiously, this happens for all file types, not just .tex files. I have no idea why this happens but I'm hoping someone familiar with UltiSnips internals would be able to test this and have some idea.

Steps to reproduce:
1) Install UltiSnips and vim-latex plugins using a plugin manager, such as vim-addon-manager or Vundle
2) Open a file of prefered type in Vim (e.g., "vim foo.py")
3) Start using a snippet with placeholders (e.g., type "def<Tab>")

Revision history for this message
 SirVer (sirver) wrote on 2012-03-03: Re: [Bug 944215] [NEW] Vim LaTeX Suite interferes with UltiSnips bindings #1

I cannot reproduce this. I cloned this repository as Latex Suite:

but all mappings work fine for me. You can also remap your snippet keys
(see UltiSnips documentation). Note that Latexsuite also adds very cheap
snippets, so there is some functional overlap in the plugins. This
guarantees trouble.

status incomplete
importance low

 Changed in ultisnips: importance: Undecided → Low status: New → Incomplete
Revision history for this message
 Jorge (skeept) wrote on 2012-03-14: #2

I can reproduce this issue.
One way of fixing this is by adding the following to your .vimrc:

"with the following c-j is not mapped to the default keys
if &filetype != 'tex'
"imap <m-C-J> <Plug>IMAP_JumpForward
"nmap <m-C-J> <Plug>IMAP_JumpForward
"vmap <m-C-J> <Plug>IMAP_JumpForward
"vmap <m-C-J> <Plug>IMAP_DeleteAndJumpForward
imap <Leader>#$<Plug>IMAP_JumpForward nmap <Leader>#$ <Plug>IMAP_JumpForward
vmap <Leader>#$<Plug>IMAP_JumpForward vmap <Leader>#$ <Plug>IMAP_DeleteAndJumpForward
endif

this just means that for any file other than latex the <c-j> should work fine with ultisnips.
In latex I actually use the default <c-j> mapping defined in the vim-latex plugin. If you also want to use the ultisnips mapping in latex remove the if statement.

The prefered mappings would be the ones that are commented out, but if I use those then I get an error in ultisnips, described in
https://bugs.launchpad.net/ultisnips/+bug/937605, so I just use some weird sequence for the mappings that I would not use otherwise.

Revision history for this message
 SirVer (sirver) wrote on 2012-03-14: #3

Are you all using the latest trunk? Are you sure about this? Because I cannot reproduce This or the bug 937605 with the latest trunk version of UltiSnips on Windows OR on Mac OS.

Revision history for this message
 Launchpad Janitor (janitor) wrote on 2012-05-14: #4

[Expired for UltiSnips because there has been no activity for 60 days.]

 Changed in ultisnips: status: Incomplete → Expired
Revision history for this message
 SirVer (sirver) wrote on 2012-05-14: #5

No answer, no fix. Speak up if you still care.

 Changed in ultisnips: status: Expired → Invalid
Revision history for this message
 Xiang Gao (gaox) wrote on 2012-08-27: #6

I can reproduce this error with latest version of ultisnips and vim-latex, and the conflict happen in INSERT mode, is it possible to fix it?

Revision history for this message
 Xiang Gao (gaox) wrote on 2012-08-27: #7

Just find out my conflict only happens in tex file and now I map it to ;j

Revision history for this message
 Matteo (gmatteo-abis+sites) wrote on 2013-07-23: #8

I still can reproduce this error with the latest version of both packages in tex files.

Revision history for this message
 SirVer (sirver) wrote on 2013-07-23: #9

Fixes welcome. Likely a clash of mappings in the plugins.

Revision history for this message
 Matteo (gmatteo-abis+sites) wrote on 2013-09-16: #10

imap <C-j> <Plug>IMAP_JumpForward

to my .vimrc fixed the problem. That looks quite strange, can somebody else check?

Revision history for this message
 Steve Mazza (spmazza) wrote on 2014-02-05: #11

It appears to be a collision, not a bug. vim latex-suite uses C-j extensively to jump outside of delimiters after expansion. UltiSnips also maps this sequence to jump to the next marker. Unfortunately I use UltiSnips extensively to expedite my LaTeX editing but I also don't think I'd be able to live without vim latex-suite. My sub-optimal solution has been to place

imap <C-j> <Plug>IMAP_JumpForward

in my .vimrc file and live without C-j functionality in UltiSnips by creating LaTeX-compatible snippets like this:

snippet exb "Beamer Example Block" b
\begin{exampleblock}{${1:Block Title}}${2:<++>}
\end{exampleblock}
endsnippet

It's inelegant and I wish there were a better solution.

Revision history for this message
 SirVer (sirver) wrote on 2014-02-05: #12

Not sure what you want to say Steve, of course it is a collision :). <C-j> is a very logical mapping for a snippet jump forward trigger, so it is no wonder that latexsuite is also using it for their pseudo snippets. You folks have a bunch of choices:

- Use another trigger for jumping forward in UltiSnips (see help, here: https://github.com/SirVer/ultisnips/blob/master/doc/UltiSnips.txt#L240)
- Use another trigger in LatexSuite (consult their help).
- Rely on a brand new feature in ultisnips that will only map jump forward and jump backwards while actually being inside a snippet. Of course you still have the conflicts, but only while you have expanded a UltiSnips snippet. Do not know if this will help anybody. For reference, the commit that implements this is here: https://github.com/SirVer/ultisnips/commit/16c46616adc9e29bd0e2e2ff53765b01b6f7ad47

 Changed in ultisnips: status: Invalid → Fix Committed
Revision history for this message
 SirVer (sirver) wrote on 2014-02-05: #13

Boldly setting to fix committed because I think the new default should deal with most awkward situations.