Last tabstop ends before the last symbol in cases with default text

[Vadim Makeev]

I have a CSS snippet for the @font-face block:

snippet @f+
@font-face {
    font-family:${1:FontFamily};
    src:url(${2:font}.eot);
    src:
        url($2.eot?iefix) format('eot'),
        url($2.woff) format('woff'),
        url($2.ttf) format('truetype'),
        url($2.svg#$2) format('svg');
    }
endsnippet

So I want to have last tab stop right after the last bracket, but it starts producing actual tab symbols right before the last bracket. Removing third line of the snippet solve everything. The same problem with the following snippet:

snippet bd+
border:${1:1px} ${2:solid} ${3:#000};
endsnippet

Last tab stop should be after semicolon, but it starts producing tabs right before it. It could be solved by adding extra space at the end of the snippet, but I don't need it in my code.

The following snippet (without default text for the tab stops) works just fine:

snippet @f
@font-face {
    font-family:$1;
    src:local($2), url($3) format($4);
    }
endsnippet

So the problem is obviously caused by ${1:blah} default value replacement.

- - -

plugins:

— pathogen
— solarized
— ultisnips

output:

2.6.6 (r266:84292, Jun 16 2011, 16:59:16)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)]

[SirVer (sirver)]

I cannot reproduce this problem with current trunk version of UltiSnips. For me, all snippets seem to work fine. Could you please provide your .vimrc, especially the UltiSnips configuration variables?

[Vadim Makeev (pepelsbey)]

I'm using 1.4 version — http://launchpad.net/ultisnips/trunk/1.4/+download/UltiSnips-1.4.tar.gz
I don't know to get latest 1.5 trunk files, so if you point me I'll try.

My .vimrc for the latest MacVim, snapshot 61:

set nocompatible
set number
set encoding=utf-8
set fileencodings=utf8,cp1251
set nowrap
set linebreak
set tabstop=4
set nofoldenable
set autoindent
set smartindent
set history=1000
set cursorline
set guicursor=
set guioptions-=T
set guifont=Consolas:h12
let macvim_hig_shift_movement=1
let loaded_matchparen = 1

" UltiSnips

let g:UltiSnipsExpandTrigger='<tab>'
let g:UltiSnipsJumpForwardTrigger='<tab>'
let g:UltiSnipsJumpBackwardTrigger='<s-tab>'

" Shortcuts

:map <silent> <c-w> :set wrap! <cr>

" Plugins

call pathogen#infect()
call pathogen#runtime_append_all_bundles()

filetype plugin indent on

" Color Theme

syntax enable
set background=light
colorscheme solarized

[SirVer (sirver)]

I cannot reproduce this problem. I am using the bd+ snippet and it behaves just like I would expect it to. I am using Macvim Snapshot 57, only your .vimrc and no plugins. I tested both, UltiSnips 1.4 and the current trunk and both work. Something else seems broken here.

Please provide the snippet definition file. If you can, please provide your whole .vim directory (you can strip it down as small as possible by removing files, as long as the error still occures it's fine).

[Vadim Makeev (pepelsbey)]

.vim directory (unstripped as it quite small) attached

[SirVer (sirver)]

I can still not reproduce this. I am using your .vimrc and your .vim directory without changes. Therefore I also use your version of ultisnips. Maybe the problem is with the keys you are typing. The following works for me:

$ mvim /tmp/blah.css
in vim: i (enter insert mode), then
bd+<tab>Hello<tab>World<tab>Blah<tab><tab>good

yields
>border:Hello World Blah; good<
without >< of course.

What is your failing test?

[Vadim Makeev (pepelsbey)]

I've found another interesting fact:

    E { bd+<tab><tab><tab><tab> }

works fine, as

    E { border:1px solid #000;<cursor> }

but:

    E {
        bd+<tab><tab><tab><tab>
    }

works wrong, as

    E {
        border:1px solid #000<cursor>;
    }

[Vadim Makeev (pepelsbey)]

Finally, I got it! To reproduce this bug you have to SKIP last value, for example:

    E {
        bd+ <tab> <tab> <tab> blah
    }

works fine as

    E {
        border:1px solid blah;<cursor>
    }

but:

    E {
        bd+ <tab> blah blah <tab> <tab>
    }

works wrong as:

    E {
        border:blah blah #000<cursor>;
    }

But E { bd+<any-combination> } works fine in any combinations, as I mentioned above.

[SirVer (sirver)]

I can still not reproduce this. All your examples in #7 work for me with your .vimrc and your .vim directory. Also if I reproduce exactly what you did in the movie posted in #6 (every keystroke), the error does not happen for me. I would like to post a similar video, but I have no idea how to do a screen capture of only one window (maybe you can help me out with a tool?).

Please try to give me an *exact* keystroke string that will reproduce the error for you. The following works for me for example:

mvim /tmp/style.css<cr>
iE {<cr><cr>}<Left><tab><up><tab>bd+<tab><tab><tab><tab><tab>hello

Gives the expected result:
>E {
 border:1px solid #000; hello
 }<

Please verify.

What a strange heisenbug this is.

[Vadim Makeev (pepelsbey)]

I'm using Lion's Quick Time to capture video, there's an option to choose only part of the screen.

After

> mvim ~/Downloads/style.css
> iE {<cr><cr>}<Left><tab><up><tab>bd+<tab><tab><tab><tab><tab>hello

I'm still getting this:

E {
    border:1px solid #000 hello;
}

But I have a few more different things: I'm using 10.7 Lion and Russian locale. I'll try to check everything under Show Leopard with English locale today.

[Vadim Makeev (pepelsbey)]

I've just tested this under Snow Leopard on my friend's macbook. Everything is fine.
Maybe it's caused by different Pyhon or other library version on Mac OS 10.7.1?

Output of the “pyhon” command:

Python 2.7.1 (r271:86832, Jun 16 2011, 16:59:05)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin

I wonder why it's different from what I mentioned in the first comment…

[Vadim Makeev (pepelsbey)]

Maybe it could explain something for you:

Python problems on Lion (mostly self-inflicted)
http://www.leancrew.com/all-this/2011/07/python-problems-on-lion-mostly-self-inflicted/

[SirVer (sirver)]

#11 is likely not our concern. MacVim links against it's own python afaik.

#10, this is interesting. Could you try changing your locale to english? Also, what happens if you try the exact same steps with vim in the console (also in both locales)? I supspect this to be somehow related to russian locales, though I have no idea what the specific problem could be.

[yugushen (yugushen)]

I confirm this bug with MacVim Snapshot 60 & 61 on Mac OS X Lion 10.7.1.

First, I can only reproduce the bug with MacVim Snapshot 60 and above, but not Snapshot 59 and below. Second, I have only tested it on Lion.

To reproduce the bug:

1. Create .vim that only contains the current trunk of UltiSnips.

2. Create .vimrc with only the following line:

    filetype plugin on

3. Download MacVim Snapshot 60 or 61 from https://github.com/b4winckler/macvim/downloads , and extract it.

4. Double click to launch MacVim. It should open a new window automatically; if not, open a new window.

5. set filetype=mkd

6. Enter insert mode, type:

    link<tab><c-j><c-j><c-j>

You will get this:

[Text](http://www.url.com)

The cursor will stop at before ')' and after 'm', but it should stop after ')'.

[SirVer (sirver)]

I can reproduce this now. I have no idea where it comes from so suddenly, does anyone know what has changed in the last few versions of macvim? Can someone check if this also happens with recent vim versions in other OSes?

[SirVer (sirver)]

We also have a bunch of failing tests with this newest macvim. I am really desperate about information about other OSes.

[SirVer (sirver)]

Okay, the problem is because the tabstop is at the end of the line. If you set virtualedit=all or add a space behind the place you expand the tabstop,everything is fine and dandy. I guess Vim has changed something internally to either feedkeys or the python command that forbids the cursor to be placed after the last char.

One resolution that I currently see is to add virtualedit=all before expanding a snippet and reverting the command when the snippet is exited. This is a non trivial change and will require some work, however I think this must be tackled ASAP because this is an annoying bug. For the moment, the best idea is to stay away from newer Vim versions :(.

I will be busy for ~2 weeks, so I will likely not be able to work on this. Volunteers are very welcome!

[yugushen (yugushen)]

I think I locate the patch that introduces the problem. It's patch v7.3.239 (http://code.google.com/p/vim/source/detail?r=0bef86c5c985218a9448fa16d935b913e67af8d5)

I compile and test both v7.3.238 and v7.3.239. The former doesn't have this bug, but the latter does. MacVim snapshot 60 is also the first version that compiles with Vim that includes this patch.

The changelog of patch v7.3.239:

    Problem: Python corrects the cursor column without taking 'virtualedit'
                into account. (lilydjwg)
    Solution: Call check_cursor_col_win().

Hope this finding can help you to fix the bug. :)

[SirVer (sirver)]

Fantastic work tracking this down! But I guess it won't help; we somehow relied on the old behaviour which allowed us to jump to the 'last column' and start visual selecting from there. I only see two solutions from here, both are hackish: the first one is to add a space at the end of each line in each snippet and remove it when we leave the snippet or to set the virtualedit=all when we expand a snippet and reset it afterwards.

I wonder why this patch was introduced into Vim. I can't understand why it made any problems the way it was before *sigh*.

[SirVer (sirver)]

ooh, a quickfix for everyone who can stand it is to use

set virtualedit=onemore

[SirVer (sirver)]

OOhh... most of what I said in #18 is wrong. Actually lilydjwg is completely right with fixing this bug and we only had a off by one error that was hidden by it.

It is fixed in r315.

[SirVer (sirver)]

Release in 1.5