on windows XP; error when def expands

[reckoner]

when the cursor is in column 1 "def" expands in the error shown below. Otherwise, when *not* in column 1, it works fine.

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Vim\vimfiles\UltiSnips-1.3\plugin\UltiSnips\__init__.py", line 647, in expand_or_jump
    rv = self._try_expand()
  File "C:\Vim\vimfiles\UltiSnips-1.3\plugin\UltiSnips\__init__.py", line 977, in _try_expand
    self._do_snippet(snippet, before, after)
  File "C:\Vim\vimfiles\UltiSnips-1.3\plugin\UltiSnips\__init__.py", line 952, in _do_snippet
    self._csnippets.append(snippet.launch(text_before, None, start))
  File "C:\Vim\vimfiles\UltiSnips-1.3\plugin\UltiSnips\__init__.py", line 378, in launch
    v, last_re = self._last_re, globals = self._globals)
  File "C:\Vim\vimfiles\UltiSnips-1.3\plugin\UltiSnips\TextObjects.py", line 946, in __init__
    self.update()
  File "C:\Vim\vimfiles\UltiSnips-1.3\plugin\UltiSnips\TextObjects.py", line 483, in update
    new_end = c.update()
  File "C:\Vim\vimfiles\UltiSnips-1.3\plugin\UltiSnips\TextObjects.py", line 493, in update
    self._do_update()
  File "C:\Vim\vimfiles\UltiSnips-1.3\plugin\UltiSnips\TextObjects.py", line 890, in _do_update
    exec self._code in self._globals, local_d
  File "<string>", line 3
    snip >> 1

[SirVer (sirver)]

Thanks for the bug report. UltiSnips was not tested on Windows, I am therefore very grateful for this report. I will not be able to fix this bug until I can get a vim version with python support. Could you help me out with that? where did you get your vim from?

I suspect this is related to line endings, but can't be sure from your error output.

[reckoner (reckoner)]

I actually built my own version VIM 7.2 that included python2.6. The
reason I built it is that the one you get from the website only included
Python version 2.5, at the time.

You might want to check the main installer at the main website.

Perhaps if you explained what this expansion is supposed to do, I can
try to generate a better error log report.

Keep up the great work!

On 2/16/2011 4:08 AM, SirVer wrote:
> Thanks for the bug report. UltiSnips was not tested on Windows, I am
> therefore very grateful for this report. I will not be able to fix this
> bug until I can get a vim version with python support. Could you help me
> out with that? where did you get your vim from?
>
> I suspect this is related to line endings, but can't be sure from your
> error output.
>
>
> ** Changed in: ultisnips
> Status: New => Confirmed
>
> ** Changed in: ultisnips
> Importance: Undecided => High
>

[SirVer (sirver)]

Thanks for your tips. I will not be able to do this for a while, because I first need to set up a virtual machine and build myself a screen and a vim version. Only then I can start investigating this problem.

In the meantime, could you please check if there is more error output? I am missing some kind of error message after the backtrace above.

[reckoner (reckoner)]

if you tell me how to capture the error you are interested, I will try.

Thanks!

On 2/16/2011 7:52 AM, SirVer wrote:
> Thanks for your tips. I will not be able to do this for a while, because
> I first need to set up a virtual machine and build myself a screen and a
> vim version. Only then I can start investigating this problem.
>
> In the meantime, could you please check if there is more error output? I
> am missing some kind of error message after the backtrace above.
>

[reckoner (reckoner)]

This blurb of code in python.snippet seems to be cause trouble

     import re, os, vim, string, random
     snip.rv = "" # Force update
     snip >> 1

what is the '>>' bitshift operator doing here?

Thanks!

On 2/16/2011 7:52 AM, SirVer wrote:
> Thanks for your tips. I will not be able to do this for a while, because
> I first need to set up a virtual machine and build myself a screen and a
> vim version. Only then I can start investigating this problem.
>
> In the meantime, could you please check if there is more error output? I
> am missing some kind of error message after the backtrace above.
>

[SirVer (sirver)]

Hi,

I have good and bad news: the good news is, I managed to get a python version of gvim running under windows (python 2.7.1). I didn't manage to get it to run in the console though which is a necessacity for running the test suite. Do you have a console vim running that can execute the :py command?

I can reproduce your problem, but I can't say where the problem is at this point in time. Debugging under windows is quite hard for me as I have no experience with it altogether. I am under the impression that this is somehow related to ts, sts or shiftwidth options. Could you please try set ts=8 sts=8 shiftwidth=8 and see if you can expand your snippets in position 1? I can, but I can't expand it in position > 7.

[reckoner (reckoner)]

Sirver:

Well, I tried setting the shiftwidth and other options as you suggested,
but that didn't help. On the other hand, I did manage to go through your
test procedure including getting screen to work on Windows. The
attachment is all of the corresponding error logs I was able to collect.
Unfortunately, I was not able to capture all of the standard output from
the "screen" window.

I hope this helps.

See attached.

On 2/17/2011 12:41 AM, SirVer wrote:
> Hi,
>
> I have good and bad news: the good news is, I managed to get a python
> version of gvim running under windows (python 2.7.1). I didn't manage to
> get it to run in the console though which is a necessacity for running
> the test suite. Do you have a console vim running that can execute the
> :py command?
>
> I can reproduce your problem, but I can't say where the problem is at
> this point in time. Debugging under windows is quite hard for me as I
> have no experience with it altogether. I am under the impression that
> this is somehow related to ts, sts or shiftwidth options. Could you
> please try set ts=8 sts=8 shiftwidth=8 and see if you can expand your
> snippets in position 1? I can, but I can't expand it in position> 7.
>

[SirVer (sirver)]

I will not have time to look over this till next week. But I am very, very interested how you managed to get your setup up? how did you make a console vim with python? Where did you get screen from?

[reckoner (reckoner)]

I built the console version from the source, linking in my own existing
Python library. I used an older copy of Visual Studio for this, but this
is probably possible using MING32 as well. I got screen to work via
cygwin. It's a little tricky to do, but I finally managed to get it going.

I hope those log files help.

Good luck!

On 2/18/2011 1:03 AM, SirVer wrote:
> I will not have time to look over this till next week. But I am very,
> very interested how you managed to get your setup up? how did you make a
> console vim with python? Where did you get screen from?
>

[Ryan Wooden (ryan.wooden)]

I've had the "joy" of working extensively in windows the past few days, so I'll chip in on this. I can't reproduce this bug on my system. I'm running windows 7, with Yongwei's build of vim 7.3 against Python 2.7, it's linked from the vim download page or here [1]. You also need the vim runtime files (again from the vim download page) in the same directory as the executables, and need to download Python 2.7. I have cygwin set up with GNU Screen, and can open my (non-cygwin) console vim inside of it, so I'll try to do some tests when I can.

[1] http://wyw.dcweb.cn/#download

[SirVer (sirver)]

Ryan, I am trying to follow along. The dcweb.cn vim version works for me under console with python, so I am one step close to running the testsuite. I installed cygwin including screen and I am able to start the dcweb.cn vim version in a cygwin window just fine. However, when I launch a screen session and start vim, nothing happens (so no vim splash screen is ever shown). I suspect a Terminal issue here, because launching vim -T xterm launches the vim session with a splashscreen, but input is all screwed up, i.e. stuff is not working.

so my question: how did you manage to launch a vim console session inside of cygwins screen?

[Ryan Wooden (ryan.wooden)]

That's what I've been trying to deal with too. I didn't get it to work, and based on what I'm seeing online, it looks like it can't be done. The windows version of vim directly accesses the console, but screen doesn't simulate the windows console.

The only real option I'm seeing for getting tests to run on windows is to rewrite the tester. I don't think this would actually be that bad of an idea. I'd like to see the testing code run in a single vim window. We could still use python to run the tests, but show the results in the quickfix window or even just a different buffer.

Thoughts?

[reckoner (reckoner)]

This is a good idea. I did manage to get it to run with screen and the
console version of vim, but it's brittle, as we have all seen. The
testing should be not be dependent on screen. It's too tricky.

Anyway, that's my opinion.

On 2/19/2011 5:01 PM, Ryan Wooden wrote:
> That's what I've been trying to deal with too. I didn't get it to work,
> and based on what I'm seeing online, it looks like it can't be done. The
> windows version of vim directly accesses the console, but screen doesn't
> simulate the windows console.
>
> The only real option I'm seeing for getting tests to run on windows is
> to rewrite the tester. I don't think this would actually be that bad of
> an idea. I'd like to see the testing code run in a single vim window. We
> could still use python to run the tests, but show the results in the
> quickfix window or even just a different buffer.
>
> Thoughts?
>

[SirVer (sirver)]

reckoner, could you enlighten us of the steps you've undertaken? It is not really important how brittle it is, once we have set it up, we can run the test suite also for future versions of UltiSnips on windows.

Rewriting the tester is most likely not possible. I chose screen because it was the only solution I found to feed vim user input in a realistic manner. I'd prefer not to be dependant on screen, but vim does not offer the functionality we currently have with tests which I think is a most to properly test the plugin. E.g. vim offers the feedkeys function that should pretty much do, what we currently do with vim. But all keys in the feedkeys() are evaluated at once; vim does not send Autocommands while the function runs and so on; the timings and call orders of our functions is completely different and we will not catch the bugs we're interested in. We could fall back to unit testing: run an ultisnips function, check if the vim buffer has changed accordingly. Frankly, this is less useful in a plugin than it is for a stand alone program, as the interplay between vim and us is what makes for the most beautiful bugs. Summary: I'd prefer a vim-only test solution; but I insisit on integration tests like we have them now and I doubt they are possible with vim only.

[reckoner (reckoner)]

Okay, here's what I did:

(1) I installed cygwin's screen.

(2) I build vim.exe (version 7.2) from the vim source using Visual
Studio and linked to Python2.6 in c:\Python26. This process is described
in the vim build documentation for Windows. I am using Windows XP.

(3) I opened two cygwin shells and typed "screen" In one of them

(4) In the other shell, I did

      % /cygdrive/c/Python26/python.exe _test.py

*Note that I don't have this in front of me right now, so I don't
remember the exact name of the test Python script. I let it run. It took
quite a long time to run the whole test. I also did not manage to catch
all of the output that was in the "screen". I don't know the requisite
screen settings to make that work.

I hope that helps.

On 2/20/2011 12:06 AM, SirVer wrote:
> reckoner, could you enlighten us of the steps you've undertaken? It is
> not really important how brittle it is, once we have set it up, we can
> run the test suite also for future versions of UltiSnips on windows.
>
> Rewriting the tester is most likely not possible. I chose screen because
> it was the only solution I found to feed vim user input in a realistic
> manner. I'd prefer not to be dependant on screen, but vim does not offer
> the functionality we currently have with tests which I think is a most
> to properly test the plugin. E.g. vim offers the feedkeys function that
> should pretty much do, what we currently do with vim. But all keys in
> the feedkeys() are evaluated at once; vim does not send Autocommands
> while the function runs and so on; the timings and call orders of our
> functions is completely different and we will not catch the bugs we're
> interested in. We could fall back to unit testing: run an ultisnips
> function, check if the vim buffer has changed accordingly. Frankly, this
> is less useful in a plugin than it is for a stand alone program, as the
> interplay between vim and us is what makes for the most beautiful bugs.
> Summary: I'd prefer a vim-only test solution; but I insisit on
> integration tests like we have them now and I doubt they are possible
> with vim only.
>

[SirVer (sirver)]

reckoner: this is quite funny, as we others did approximately the same, but for us, vim doesn't start inside the screen session. Maybe the way you build vim yourself makes the difference? Could you verify that when you use the vim version from [1] that vim does no longer start inside the screen session for you as well?

[1] http://wyw.dcweb.cn/#download

[Ryan Wooden (ryan.wooden)]

I'm trying to put together a testing system for windows using COM. It's currently a bit of a hack, but the tests still all run under Linux, and most of the tests are passing under windows.

Currently, the only tests failing on windows on my machine are:
- All of the ShellCode Interpolation tests, which is expected, since windows doesn't come with bash/sh
- RecTabStopsWithExpandtab_SpecialIndentProblem_ECR, this is putting a tab where there apparently shouldn't be one
- SnippetOptions_ExpandInwordSnippetsWithOtherChars_Expand3, this fails miserably, because windows is interpreting the unicode character as an escape sequence and doing something with the menu. I'm not sure how to send unicode characters properly with COM, so this one may need to be skipped on windows.

I'm occasionally getting other errors too, but they seem to be timing issues, since if I run the tests again, they work.

Sending key presses under windows is very different. I'm using COM to focus a window with a title ending in "- GVIM" (which is assumed to be already running, and have its current directory set to the ultisnips directory), then I focus it, and start sending keys to it. The main problem is that if you change which window has focus (eg. by clicking) then all of the key press events start getting sent to the new window! I'm not sure if there's a way to get around this, but for the moment, you just need to let the tests run their course, or risk blowing things up.

I've pushed a new branch (windows-testing) which has the new code in it. It requires the pywin32 modules from [1] to run.

[1] http://sourceforge.net/projects/pywin32/

[reckoner (reckoner)]

Additionally, you might want to look into pywinauto. It uses SendKeys
(rutherford.net) to simulate the keypresses and send keypresses to controls.

With respect to keeping the keystrokes in the correct window, it is
actually pretty difficult. Basically, you have to get the handle to the
control and make sure the keystrokes are sent to it. This is different
from relying on the VIM window to be in the foreground, since it will
work even if it's not in the foreground ( since it has the window's
handle ). The downside of this approach is that you have to use
postmessage or sendMessage to point the keystrokes one by one at the
appropriate window handle. It is doable, but extremely tedious,
especially if the keystroke sequences are long and complex.

Alternatively, you might want to look into dragonfly
(http://code.google.com/p/dragonfly/), which is an automation system
that is controllable by using speech recognition. Note that you did not
need the speech recognition part in order to use it, since it's just
another very comprehensive python module with deep windows hooks.

Good luck!

On 2/20/2011 9:15 AM, Ryan Wooden wrote:
> I'm trying to put together a testing system for windows using COM. It's
> currently a bit of a hack, but the tests still all run under Linux, and
> most of the tests are passing under windows.
>
> Currently, the only tests failing on windows on my machine are:
> - All of the ShellCode Interpolation tests, which is expected, since windows doesn't come with bash/sh
> - RecTabStopsWithExpandtab_SpecialIndentProblem_ECR, this is putting a tab where there apparently shouldn't be one
> - SnippetOptions_ExpandInwordSnippetsWithOtherChars_Expand3, this fails miserably, because windows is interpreting the unicode character as an escape sequence and doing something with the menu. I'm not sure how to send unicode characters properly with COM, so this one may need to be skipped on windows.
>
> I'm occasionally getting other errors too, but they seem to be timing
> issues, since if I run the tests again, they work.
>
> Sending key presses under windows is very different. I'm using COM to
> focus a window with a title ending in "- GVIM" (which is assumed to be
> already running, and have its current directory set to the ultisnips
> directory), then I focus it, and start sending keys to it. The main
> problem is that if you change which window has focus (eg. by clicking)
> then all of the key press events start getting sent to the new window!
> I'm not sure if there's a way to get around this, but for the moment,
> you just need to let the tests run their course, or risk blowing things
> up.
>
> I've pushed a new branch (windows-testing) which has the new code in it.
> It requires the pywin32 modules from [1] to run.
>
>
> [1] http://sourceforge.net/projects/pywin32/
>

[reckoner (reckoner)]

 From looking at the link you provided, I get the feeling that he put a
lot more into his VIM build than I did, I also think he used MING32
instead of Microsoft Visual Studio. In other words, it's a lot more
sophisticated than what I did.

I won't be able to verify this for some time, however, since I'm
traveling right now. I'll get to it when I get back around March 1. I
have the feeling that you all will figure it out by then, however :).

Good luck!

On 2/20/2011 8:46 AM, SirVer wrote:
> reckoner: this is quite funny, as we others did approximately the same,
> but for us, vim doesn't start inside the screen session. Maybe the way
> you build vim yourself makes the difference? Could you verify that when
> you use the vim version from [1] that vim does no longer start inside
> the screen session for you as well?
>
> [1] http://wyw.dcweb.cn/#download
>

[SirVer (sirver)]

Ryan, I just tested your COM proof of concept and I think this is the way to go. I was able to run the testsuite with 28 failures and 1 error and I saw quite some red text scrolling. We should concentrate on making the test suite more modular and attach flags to some tests (for example skip_on_windows=True, similarly skip_on_unix=True) and then - obviously - fix the remaining windows errors.

I will stop looking into screen now, windows get's it's own test runner. Good work; I would never have been able to come up with this solution.

[Ryan Wooden (ryan.wooden)]

Okay, I cleaned up the windows testing. It tries to focus the gvim window every time before sending keys to it, but if it tries, and you unfocus it again before it sends the keys, it stops testing (the only way I could find to do this was to throw KeyboardInterrupt, which I don't like).

I added skip_on_{windows,linux,mac} attributes to the test classes, and I have the shell tests skipping on windows. If you have unittest2.0+ installed, then they actually show up as skipped tests, otherwise they show up as successful tests.

I'm only getting 2 failures now, the same two as before.

[SirVer (sirver)]

Sounds good. Should I go ahead and merge your changes?

[Ryan Wooden (ryan.wooden)]

Sure. As far as I know, my changes haven't fixed the original bug, but I've never been able to duplicate the bug anyway, so we probably shouldn't close the bug yet.

[SirVer (sirver)]

Just to let you know, I am working on this on and off. I concentrate to get the test suite run under windows, currently I have 5 failures left.

I tracked one bug: my system expects a second keystroke after `, so to write this character, I have to type `+SPACE. This screwed up some off the snippets when passed through sendkeys. The way i fixed this is to replace all occurences of this with `+_+BS which should become a simple ` on all systems. Obviously the same holds for ´.

[SirVer (sirver)]

Alright, I fixed the testsuite and all tests pass now on my system except for RecTabStopsWithExpandtab_SpecialIndentProblem_ECR. It seems like the mac version and the windows version of vim behave differently and I am quite confident that this is not related to ultisnips, but I am not sure yet.

I had to trick around with unicode and utf-8 encoding a bit, but things seem to be in order now.

However, while working on this, I found a reliable way to produce the symptons that are described in the original post. I wrote a quick UnitTest for it (PythonCode_IndentProblem) and this test fails reliably on my system. The problem is concerned with indent conversion between tab and spaces while parsing snippet objects, I think we ignore the expandtabs variable in one wrong spot, but I have no time to investigate this further.

I feel we are on a good way to fix this soon.

[SirVer (sirver)]

I committed a fix for the error I encountered in r274. Reckoner, could you verify that this fixes the problem you describe in your original post?

[reckoner (reckoner)]

Sirver:

I pulled the latest trunk from launchpad using:

% bzr branch lp:ultisnips

and updated the files in the vimfiles tree.

I still get a similar looking error, but I get the feeling I'm the only
one experiencing this problem. It's probably something in my
configuration or build since I build my own VIM and link to Python 2.6.

Thanks for keeping up with this. Note that if I am not in column 1, then
I can successfully expand with no problem.

---------------------------------
An error occured. This is either a bug in UltiSnips or a bug in a
snippet definition. If you think this is a bug, please report it to
https://bugs.launchpad.net/ultisnips/+filebug.

Following is the full stack trace:
Traceback (most recent call last):
   File "C:\Vim\vimfiles\UltiSnips-1.3\plugin\UltiSnips\__init__.py",
line 40, in wrapper
     return f(*args, **kwds)
   File "C:\Vim\vimfiles\UltiSnips-1.3\plugin\UltiSnips\__init__.py",
line 639, in expand_or_jump
     rv = self._try_expand()
   File "C:\Vim\vimfiles\UltiSnips-1.3\plugin\UltiSnips\__init__.py",
line 980, in _try_expand
     self._do_snippet(snippet, before, after)
   File "C:\Vim\vimfiles\UltiSnips-1.3\plugin\UltiSnips\__init__.py",
line 955, in _do_snippet
     self._csnippets.append(snippet.launch(text_before, None, start))
   File "C:\Vim\vimfiles\UltiSnips-1.3\plugin\UltiSnips\__init__.py",
line 401, in launch
     v, last_re = self._last_re, globals = self._globals)
   File "C:\Vim\vimfiles\UltiSnips-1.3\plugin\UltiSnips\TextObjects.py",
line 946, in __init__
     self.update()
   File "C:\Vim\vimfiles\UltiSnips-1.3\plugin\UltiSnips\TextObjects.py",
line 483, in update
     new_end = c.update()
   File "C:\Vim\vimfiles\UltiSnips-1.3\plugin\UltiSnips\TextObjects.py",
line 493, in update
     self._do_update()
   File "C:\Vim\vimfiles\UltiSnips-1.3\plugin\UltiSnips\TextObjects.py",
line 890, in _do_update
     exec self._code in self._globals, local_d
   File "<string>", line 3
     snip >> 1

^
SyntaxError: invalid syntax

On 3/28/2011 10:04 PM, SirVer wrote:
> I committed a fix for the error I encountered in r274. Reckoner, could
> you verify that this fixes the problem you describe in your original
> post?
>
> ** Changed in: ultisnips
> Status: Confirmed => Fix Committed
>

[SirVer (sirver)]

Could you pack your .vim vimrc and snippet files all together and send them to me? Maybe we can still sort this out.

[SirVer (sirver)]

or upload them here.

[Ryan Wooden (ryan.wooden)]

Is that '^' showing up in the right place on the bug tracker? If not, what is it pointing at?

[reckoner (reckoner)]

Sirver:

I am attaching what I have installed for ultisnips. Based on the earlier
instructions, I do the following in my _vimrc

set runtimepath+=$VIM/vimfiles/UltiSnips-1.3
let g:UltiSnipsExpandTrigger="<tab>"
let g:UltiSnipsJumpForwardTrigger="<tab>"
let g:UltiSnipsJumpBackwardTrigger="<s-tab>"

I hope that helps. Is there a way to test ultisnips in isolation from
all of the other plug-ins I have installed?

On 3/29/2011 9:04 AM, SirVer wrote:
> Could you pack your .vim vimrc and snippet files all together and send
> them to me? Maybe we can still sort this out.
>
> ** Changed in: ultisnips
> Status: Fix Committed => Confirmed
>

[SirVer (sirver)]

The files you have attached work for me with a minimal vimrc, they also pass all tests. I think an esoteric vim option or plugin makes the problem.

You can test UltiSnips in isolation by running the test.py script. Under windows, you have to fire a up a gvim that is not parsing your vimrc; I always do this from the console with gvim -u NONE. You can then run the test.py script in the UltiSnips top level directory: python test.py. Don't touch your mouse/keyboard till the tests are through.

[reckoner (reckoner)]

I'm attaching my run of the test.py pursuant to your instructions. There
are a number of failures, but I'm not sure that's not normal. See below.

---------
C:\Vim\vimfiles\UltiSnips-1.3
 >gvim -u NONE

C:\Vim\vimfiles\UltiSnips-1.3
 >python.exe test.py
.........................................................F..........F......F....
......................FFFF......FF....F.FF...FF....F.FFFFFFFFF..FFF.............
..........F.................F...................................FFFFFFF.........
.........................................................................
======================================================================
FAIL: runTest (test.Multiple_ManySnippetsOneTrigger_ECR)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Vim\vimfiles\UltiSnips-1.3\test.py", line 196, in runTest
     def runTest(self): self.check_output()
   File "C:\Vim\vimfiles\UltiSnips-1.3\test.py", line 194, in check_output
     self.assertEqual(self.output, wanted)
AssertionError: None != ' --- some text before --- \n\ntesthi\n\n ---
some text
after --- '

======================================================================
FAIL: runTest (test.No_Tab_Expand_Leading_Tabs)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Vim\vimfiles\UltiSnips-1.3\test.py", line 196, in runTest
     def runTest(self): self.check_output()
   File "C:\Vim\vimfiles\UltiSnips-1.3\test.py", line 194, in check_output
     self.assertEqual(self.output, wanted)
AssertionError: ' --- some text before --- \n\nte\tst\t\n\n --- some
text after
--- ' != ' --- some text before --- \n\n\t\t\tExpand\tme!\t\n\n --- some
text af
ter --- '

======================================================================
FAIL: runTest (test.ParseSnippets_Global_Local_Python)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Vim\vimfiles\UltiSnips-1.3\test.py", line 196, in runTest
     def runTest(self): self.check_output()
   File "C:\Vim\vimfiles\UltiSnips-1.3\test.py", line 194, in check_output
     self.assertEqual(self.output, wanted)
AssertionError: 'An error occured. This is either a bug in UltiSnips or
a bug in
  a\nsnippet definition. If you think this is a bug, please report it
to\nhttps:/
/bugs.launchpad.net/ultisnips/+filebug.\n\nFollowing is the full stack
trace:\nT
raceback (most recent call last):\n File
"C:\\Vim\\vimfiles\\UltiSnips-1.3\\plu
gin\\UltiSnips\\__init__.py", line 40, in wrapper\n return f(*args,
**kwds)\n
   File
"C:\\Vim\\vimfiles\\UltiSnips-1.3\\plugin\\UltiSnips\\__init__.py", line
612, in expand\n if not self._try_expand():\n File
"C:\\Vim\\vimfiles\\UltiS
nips-1.3\\plugin\\UltiSnips\\__init__.py", line 980, in _try_expand\n
  self._d
o_snippet(snippet, before, after)\n File
"C:\\Vim\\vimfiles\\UltiSnips-1.3\\plu
gin\\UltiSnips\\__init__.py", line 955, in _do_snippet\n
self._csnippets.appe
nd(snippet.launch(text_before, None, start))\n File
"C:\\Vim\\vimfiles\\UltiSni
ps-1.3\\plugin\\UltiSnips\\__init__.py", line 401, in launch\n v,
last...

[SirVer (sirver)]

Uuh, i smell the Problem now. Could you please post the Output of
:py import sys; print(sys.version)

[reckoner (reckoner)]

here it is:

2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)]

Thanks!

On 3/29/2011 2:10 PM, SirVer wrote:
> Uuh, i smell the Problem now. Could you please post the Output of
> :py import sys; print(sys.version)
>

[reckoner (reckoner)]

Sorry. this is it:

2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]

On 3/29/2011 2:10 PM, SirVer wrote:
> Uuh, i smell the Problem now. Could you please post the Output of
> :py import sys; print(sys.version)
>

[SirVer (sirver)]

Thanks! I finally found the problem: The exec statement under python 2.6 does not cope with windows style line endings ("\r\n") [1] and it seems like python 2.7 does not have the problem (though the documentation states otherwise). I couldn't reproduce the problem under Mac and python 2.6 because there are no windows line endings under Mac.

However, preprocessing the python code that gets executed by replacing "\r\n" through "\n" gives a fast and simple solution to the problem. Under windows and python 2.6.4 all tests that are not skipped pass for me now.

reckoner, could you please verify that your original problem is gone with r276. Could you also run the testsuite again?

Thanks for the persistence in tracking this down!

[1] http://docs.python.org/release/2.6.6/reference/simple_stmts.html#id2

[SirVer (sirver)]

Given things work now correctly for reckoner on windows, I feel this bug is a big step towards 1.4. Basically it means that UltiSnips supports all systems that Vim supports.

[reckoner (reckoner)]

I can confirm the bug that was originally reported has been fixed! Great
job!

As requested, I ran the test suite again. There were a number of
failures, but that might be normal. Here is the output:

C:\Vim\vimfiles\UltiSnips-1.3
 >gvim -u NONE

C:\Vim\vimfiles\UltiSnips-1.3
 >python test.py
...............................F.........................F..........F..........
........................FF......F......FFF...FF.F..F.FFFFFFFFF..FFF............
..........F.....F.F................FF...........................FFFFFFF........
.........................................................................
======================================================================
FAIL: runTest (test.ListAllAvailable_NothingTyped_ExceptCorrectResult)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Vim\vimfiles\UltiSnips-1.3\test.py", line 196, in runTest
     def runTest(self): self.check_output()
   File "C:\Vim\vimfiles\UltiSnips-1.3\test.py", line 194, in check_output
     self.assertEqual(self.output, wanted)
AssertionError: None != ' --- some text before --- \n\nOHEEEE\n\n ---
some text
after --- '

======================================================================
FAIL: runTest (test.Multiple_ManySnippetsOneTrigger_ECR)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Vim\vimfiles\UltiSnips-1.3\test.py", line 196, in runTest
     def runTest(self): self.check_output()
   File "C:\Vim\vimfiles\UltiSnips-1.3\test.py", line 194, in check_output
     self.assertEqual(self.output, wanted)
AssertionError: None != ' --- some text before --- \n\ntesthi\n\n ---
some text
after --- '

======================================================================
FAIL: runTest (test.No_Tab_Expand_Leading_Tabs)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Vim\vimfiles\UltiSnips-1.3\test.py", line 196, in runTest
     def runTest(self): self.check_output()
   File "C:\Vim\vimfiles\UltiSnips-1.3\test.py", line 194, in check_output
     self.assertEqual(self.output, wanted)
AssertionError: ' --- some text before --- \n\nte\tst\t\n\n --- some
text after
--- ' != ' --- some text before --- \n\n\t\t\tExpand\tme!\t\n\n --- some
text a
ter --- '

======================================================================
FAIL: runTest (test.PythonCode_MultiAppendShift)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Vim\vimfiles\UltiSnips-1.3\test.py", line 196, in runTest
     def runTest(self): self.check_output()
   File "C:\Vim\vimfiles\UltiSnips-1.3\test.py", line 194, in check_output
     self.assertEqual(self.output, wanted)
AssertionError: ' --- some text before --- \n\n\ntes\tt\t\n\n --- some
text aft
r --- ' != ' --- some text before ---
\n\n\n\thi\n\ti1\n\ti1\n\t\ti2\ni0\n\t\t\
i3\n\tEnd\n\n --- some text after --- '

======================================================================
FAIL: runTest (test.PythonCode_MultiAppendShiftMethods)
-------------------------------------...

[SirVer (sirver)]

Grr... I was positive that the test pass now. It is likely that you run into other problems down the road.

If can only fix errors I can investigate. I am most likely not able to duplicate your setup exactly though. Is it possible to send me your self made gvim.exe. If the problem lies in any of the vim startup files though, that will not suffice. I am also not so firm with windows, but I guess all DLLs should be available on my virtual box. Maybe I can reproduce the errors then.

[reckoner (reckoner)]

I think it's fair to call this bug "closed". I look forward to the
formal release. If you get reports of other weird problems of this kind,
I will try to help; but I think you have thoroughly explored it,
especially with the development of the windows-based testing suite.

Thanks!

On 3/30/2011 1:44 PM, SirVer wrote:
> Grr... I was positive that the test pass now. It is likely that you run
> into other problems down the road.
>
> If can only fix errors I can investigate. I am most likely not able to
> duplicate your setup exactly though. Is it possible to send me your self
> made gvim.exe. If the problem lies in any of the vim startup files
> though, that will not suffice. I am also not so firm with windows, but I
> guess all DLLs should be available on my virtual box. Maybe I can
> reproduce the errors then.
>
>
> ** Changed in: ultisnips
> Status: Fix Committed => Incomplete
>

[SirVer (sirver)]

Okay, Fix committed it is then. Thanks for your help!

[SirVer (sirver)]

Release in 1.4.

[reckoner (reckoner)]

Congratulations on the new release!

I haven't found any problems with it on Windows (yet).

Thanks again

On 7/17/2011 4:17 AM, SirVer wrote:
> Release in 1.4.
>
> ** Changed in: ultisnips
> Status: Fix Committed => Fix Released
>

[SirVer (sirver)]

Thanks :)