Re: visual_studio.vim
Max, are you still developing an async version of visual_studio.vim? Is there somewhere we can find it? I started using VS 2010 and I'd like to get Vim integration working. (I grabbed the vim.org version of the script and only Get/Put file worked.) I'm late to the party, but for async vim implementation, you could look at my AsyncCommand https://github.com/pydave/AsyncCommand vimscript. It's setup to handle the async implementation details for Windows and Unix and you just pass it what to do and how to handle the result (when the job completes). -David https://github.com/pydave/AsyncCommand -- You received this message from the vim_use maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: visual_studio.vim help?
... The vim.org script page for visual_studio.vim (I assume this is what you're using: http://www.vim.org/scripts/script.php?script_id=864 ) says that the last release was in 2007. Perhaps the Express version of 2008 hadn't even been released? It also appears to require a fairly old version of Python (2.4), and states that the version should be the same as the version Vim was built with. Recent Windows Vims are built with support for 2.6 and/or 3.0. Maybe there are Python compatibility problems. Since I recently updated to Windows 7 (64-bit), I am using Python 2.6 (I compile my own Vim) and VS 2008 with this plugin without issues. I know it is not related to the Express version of Visual Studio, but it does show that it also works with newer versions of Python. HTH, Dave -- You received this message from the vim_use maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: visual_studio.vim help?
On Sun, 26 Sep 2010, Tony Miller wrote: Has anyone here gotten the visual_studio.vim plugin to work? I'm trying to use it with VisualStudio 2008 Express. I tried clicking on refresh under projects and I get: Retrieving projects... Cannot access VisualStudio. Not running? No projects found I do in fact have visual studio running, with a project open. Any ideas? The 'Express' versions of Visual Studio don't support Visual Studio plugins. It wouldn't surprise me to find that lack of VS plugin support might also prevent external programs from accessing what they would need to access. The vim.org script page for visual_studio.vim (I assume this is what you're using: http://www.vim.org/scripts/script.php?script_id=864 ) says that the last release was in 2007. Perhaps the Express version of 2008 hadn't even been released? It also appears to require a fairly old version of Python (2.4), and states that the version should be the same as the version Vim was built with. Recent Windows Vims are built with support for 2.6 and/or 3.0. Maybe there are Python compatibility problems. -- Best, Ben -- You received this message from the vim_use maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: visual_studio.vim
On 18/01/10 19:45, Max Dyckhoff wrote: Otherwise, I was unable to background-execute my perl script with start from my win32-gvim. It was quite a long time ago, I don't remember what were the various ways I tried back then. Hence I cannot tell without testing it whether Ben's solution will actually work. Testing at home (no Visual Studio!) shows that the :!start idea will work fine. I wrote a batch file which contains: c:\Program Files\Mozilla Firefox\firefox.exe c:\Program Files\vim\vim72\gvim.exe --remote-send :cfile test.cfileCR Then from inside vim I run: :!startbatchfile. As soon as I quit Firefox, my testfile is opened as the error file in Vim. Of course the downside of this is that if the remote-send executes while I am in the middle of editing a file, it just enters that text into the file. It should be easy enough to figure out a nice solution for that though Max gvim --remote-send C-\C-N:drop test.cfileCR :help CTRL-\_CTRL-N :help :drop Best regards, Tony. -- Linux is just like a wigwam: no Windows, no Gates and an Apache inside. -- You received this message from the vim_use maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: visual_studio.vim
On Jan 25, 6:59 pm, Max Dyckhoff max.dyckh...@gmail.com wrote: Upon a quick skim, it seems like you have removed support for using external Python, and rely on vim's built in Python; is that accurate? My async version requires external Python, for obvious reasons, unless you can suggest an alternative? Cheers, Max Yes, I thought the allowance for calling an external Python was superfluous, since both the official and Cream's build of Vim are built with Python support. It just added an unnecessary complexity. You say that the async version requires external Python for obvious reasons. I'm not sure I understand what you mean. Calls to system() or commands using :! are no less blocking than commands using :python. The COM calls to the Visual Studio DTE are non-blocking, and the blocking mechanism is implemented in the visual_studio.py module using a loop that checks if the build is complete. For the async-version, you should disable this wait loop. Regards, Henrik. On Mon, Jan 25, 2010 at 9:37 AM, Henrik Öhman spe...@gmail.com wrote: On Jan 25, 3:53 pm, Max Dyckhoff max.dyckh...@gmail.com wrote: That's what I'm doing! :) :) I'm actually in the process of writing (whenever my project is compiling) an asynchronous version of visual_studio.vim that can be turned on with a global. It's great so far, I just need a few more hours to finalize everything. Is the author (Michael Graz) still around, and would anyone else be interested in seeing my async version? Max He has responded to email in the past. I've forked the project, because I wanted to implement some functionality of my own, and felt like I wanted to rewrite most of it to get a better separation of Vim and Python code. Feel free to use it if you like - it's fairly well tested, but some bugs are still there. You can find it athttp://github.com/spiiph/visual_studio. Regards, Henrik -- You received this message from the vim_use maillist. For more information, visithttp://www.vim.org/maillist.php -- You received this message from the vim_use maillist. For more information, visit http://www.vim.org/maillist.php
Re: visual_studio.vim
You say that the async version requires external Python for obvious reasons. I'm not sure I understand what you mean. Calls to system() or commands using :! are no less blocking than commands using :python. The COM calls to the Visual Studio DTE are non-blocking, and the blocking mechanism is implemented in the visual_studio.py module using a loop that checks if the build is complete. For the async-version, you should disable this wait loop. Very true, that's what I'm doing. Not sure what I was thinking saying I needed external Python for that! :) Max -- You received this message from the vim_use maillist. For more information, visit http://www.vim.org/maillist.php
Re: visual_studio.vim
Yes, I thought the allowance for calling an external Python was superfluous, since both the official and Cream's build of Vim are built with Python support. It just added an unnecessary complexity. Henrik, Upon trying out your version of visual_studio.py and visual_studio.vim, I got some errors in the log_func() calls, specifically: AttributeError: 'tuple' object has no attribute 'args' (line 790) I believe this is because you are relying on Python 2.6 functionality, while I am using Python 2.5; does that seem accurate? It's a very easy fix to make it work with 2.5 of course, just be explicit with the return tuple from getargvalues(), thus: args,varargs,varkw,locals = inspect.getargvalues(frame[0]) And of course, fix the corresponding uses of arg_info. Other than that the script works great; I have my asynchronous version working already and I'll share it soon. Max -- You received this message from the vim_use maillist. For more information, visit http://www.vim.org/maillist.php
Re: visual_studio.vim
Yes, I thought the allowance for calling an external Python was superfluous, since both the official and Cream's build of Vim are built with Python support. It just added an unnecessary complexity. Henrik, Upon trying out your version of visual_studio.py and visual_studio.vim, I got some errors in the log_func() calls, specifically: AttributeError: 'tuple' object has no attribute 'args' (line 790) I believe this is because you are relying on Python 2.6 functionality, while I am using Python 2.5; does that seem accurate? It's a very easy fix to make it work with 2.5 of course, just be explicit with the return tuple from getargvalues(), thus: args,varargs,varkw,locals = inspect.getargvalues(frame[0]) And of course, fix the corresponding uses of arg_info. Other than that the script works great; I have my asynchronous version working already and I'll share it soon. Actually, Henrick, it seems like there are a multitude of bugs in your branch of the script; build_solution and build_project both start throwing errors. It could be that it just supports Python 2.6, but it shouldn't be difficult to make it backwards compatible with Python 2.5. My async stuff works great, although sadly it currently only works with compile_file, as the other two are blocked from working because of the errors. If you'd like more information on what is failing let me know; it might be best to take this discussion off the vim mailing list though. Max -- You received this message from the vim_use maillist. For more information, visit http://www.vim.org/maillist.php
Re: visual_studio.vim
On Mon, Jan 25, 2010 at 6:28 AM, Henrik Öhman spe...@gmail.com wrote: There's a command for this in visual_studio.vim: :DTEOutput You've gotten some suggestions on how to start the build in the background. I'd just keep a Visual Studio running with the project, connect to that DTE instance, start the build from Visual Studio, and then just use :DTEOutput when the build is finished. That's what I'm doing! :) I'm actually in the process of writing (whenever my project is compiling) an asynchronous version of visual_studio.vim that can be turned on with a global. It's great so far, I just need a few more hours to finalize everything. Is the author (Michael Graz) still around, and would anyone else be interested in seeing my async version? Max -- You received this message from the vim_use maillist. For more information, visit http://www.vim.org/maillist.php
Re: visual_studio.vim
On Jan 15, 2:31 pm, Max max.dyckh...@gmail.com wrote:
Does anyone
know if it would be possible to make a non-blocking build command?
In general no, Vim does not support non-blocking commands.
In this case, you *might* be able to do something like ':!start {build
command} {error file} vim --remote-send :cfile {error file}
CR' instead of :make but I don't know whether this will succeed
or not.
Two tricks here. See
:help :!start
:help --remote-send
The idea is to run an asynchronous command in an external process and
then load the results into Vim.
--
You received this message from the vim_use maillist.
For more information, visit http://www.vim.org/maillist.php
Re: visual_studio.vim
Hello,
Ben Fritz fritzophre...@gmail.com wrote:
On Jan 15, 2:31 pm, Max max.dyckh...@gmail.com wrote:
Does anyone know if it would be possible to make
a non-blocking build command?
In general no, Vim does not support non-blocking commands.
In this case, you *might* be able to do something like ':!start
{build command} {error file} vim --remote-send :cfile {error file}
CR' instead of :make but I don't know whether this will succeed
or not.
That's what I've used in BTH [1] -- that only works under unix, and that
actually do a few more thing other than a :cfile.
IIRC, Marc Weber wrote another plugin for background compilation that works
under Windows as well.
[1] http://code.google.com/p/lh-vim/source/browse/#svn/BTW/trunk
--
Luc Hermitte
http://lh-vim.googlecode.com/
http://hermitte.free.fr/vim/
--
You received this message from the vim_use maillist.
For more information, visit http://www.vim.org/maillist.php
Re: visual_studio.vim
A cursory search turns up nothing about that, sadly.
In your experience, which part of Ben Fritz's solution didn't work?
I'm away from the office today so I'll be unable to try it til
Tuesday, but thanks for the suggestions; I'll let you know what happens.
Max
Sent from my iPhone.
On Jan 18, 2010, at 7:33 AM, Luc Hermitte hermi...@free.fr wrote:
Hello,
Ben Fritz fritzophre...@gmail.com wrote:
On Jan 15, 2:31 pm, Max max.dyckh...@gmail.com wrote:
Does anyone know if it would be possible to make
a non-blocking build command?
In general no, Vim does not support non-blocking commands.
In this case, you *might* be able to do something like ':!start
{build command} {error file} vim --remote-send :cfile {error
file}
CR' instead of :make but I don't know whether this will succeed
or not.
That's what I've used in BTH [1] -- that only works under unix, and
that actually do a few more thing other than a :cfile.
IIRC, Marc Weber wrote another plugin for background compilation
that works under Windows as well.
[1] http://code.google.com/p/lh-vim/source/browse/#svn/BTW/trunk
--
Luc Hermitte
http://lh-vim.googlecode.com/
http://hermitte.free.fr/vim/
--
You received this message from the vim_use maillist.
For more information, visit http://www.vim.org/maillist.php
--
You received this message from the vim_use maillist.
For more information, visit http://www.vim.org/maillist.php
Re: visual_studio.vim
Max Dyckhoff max.dyckh...@gmail.com wrote:
A cursory search turns up nothing about that, sadly.
In your experience, which part of Ben Fritz's solution didn't work?
I'm away from the office today so I'll be unable to try it til
Tuesday, but thanks for the suggestions; I'll let you know what
happens.
Otherwise, I was unable to background-execute my perl script with start from
my win32-gvim. It was quite a long time ago, I don't remember what were the
various ways I tried back then. Hence I cannot tell without testing it whether
Ben's solution will actually work.
The background compilation in BTH exists the way it does in order to do a few
other things (related to _background_ compilation):
- it removes the temporary file once read,
- it executes hooks of the quickfix windows if any where defined (syntax
coloring)
- it permits to configure the desired maximum size for the qf window.
On Jan 18, 2010, at 7:33 AM, Luc Hermitte hermi...@free.fr wrote:
[...]
In general no, Vim does not support non-blocking commands.
In this case, you *might* be able to do something like ':!start
{build command} {error file} vim --remote-send :cfile {error
file} CR' instead of :make but I don't know whether this will
succeed or not.
That's what I've used in BTH [1] -- that only works under unix, and
that actually do a few more thing other than a :cfile.
[...]
--
Luc Hermitte
http://lh-vim.googlecode.com/
http://hermitte.free.fr/vim/
--
You received this message from the vim_use maillist.
For more information, visit http://www.vim.org/maillist.php
Re: visual_studio.vim
Otherwise, I was unable to background-execute my perl script with start from my win32-gvim. It was quite a long time ago, I don't remember what were the various ways I tried back then. Hence I cannot tell without testing it whether Ben's solution will actually work. Testing at home (no Visual Studio!) shows that the :!start idea will work fine. I wrote a batch file which contains: c:\Program Files\Mozilla Firefox\firefox.exe c:\Program Files\vim\vim72\gvim.exe --remote-send :cfile test.cfileCR Then from inside vim I run: :!start batchfile. As soon as I quit Firefox, my testfile is opened as the error file in Vim. Of course the downside of this is that if the remote-send executes while I am in the middle of editing a file, it just enters that text into the file. It should be easy enough to figure out a nice solution for that though Max -- You received this message from the vim_use maillist. For more information, visit http://www.vim.org/maillist.php
