Comment 15 for bug 719649

Revision history for this message
reckoner (reckoner) wrote : Re: [Bug 719649] Re: on windows XP; error when def expands

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.
>