I'm trying to setup vim on windows to work like it does in Linux. Basically, when I type ":make" in linux, I get the output of makeprg sort of streaming through vim itself.
On windows I get a cmd prompt that comes up, but behind vim. I have to switch focus to view the results until they are finished and then they can be viewed in the quickfix window.
I attempted to download a copy of "tee" and set shellpipe to |tee, but that didn't really change anything. Below are the sort of relevant settings in my vimrc, I use ninja, but the same happens if I switch to nmake or something similar.
set makeprg=ninja\ -C\ build-ninja
set shellpipe=2>&1\ \|tee
set efm+=%Dninja:\ Entering\ directory\ `%f',%Xninja:\ leaving\ directory
I think this is related to what you want, but provides only for a partial solution, because it will not wait until the program has finished running:
set makeprg=start\ /min\ ninja\ -C\ build-ninja
Getting it to work will not be trivial (see comments), it seems like an important oversight of the Windows version of Vim, because start cannot be executed from makeprg (see comments), only the internal (and more limited !start).
The full documentation of the start program (which it seems you would need to somehow invoke) you can find in this question
Related
I am on windows machine, when I temporarily change to console using :sh then back to vim with exit command and then again back to console and it starts over. this causes me to lose my previous directory. Is there other way returning back to vim won't start the shell over?
Not really
https://stackoverflow.com/a/12089631/1427295
GVIM does not retain a "handle" to the shell that launched it in a way
that allows it to send commands back to it. Because of they
synchronous execution, you also cannot launch a shell from GVIM, keep
feeding it commands while also continue working in GVIM.
I'm afraid you have to use the functionality of your window manager to
launch (and then later re-activate) a shell window, and send the
commands as keystrokes to it. On Windows, this can be done (e.g. in
VBScript) via WshShell's Run(), AppActivate() and SendKeys() methods;
there are probably similar mechanisms for window control on Linux,
too.
If you don't mind having that shell inside your GVIM (emulated, with
all its drawbacks), though, there are plugins that enable that.
https://serverfault.com/a/95405
The Windows command interpreter ("cmd.exe") doesn't provide any
support for saving/exporting/keeping history, of, if it does,
Microsoft didn't document it and nobody was ever able to find it. You
can of course try to work around that, like Sean suggested, but
there's (or does appear to be) no built-in support for this
You may be able to output your command history using echo %cd% > prev_dir.txt then create a script that cds to the directory in prev_dir.txt, but you'd still have to remember to save your directory to the file before you exit the shell each time.
This is related to debugging the issue mentioned in: Plugin (vim-latex) crashing gVim on startup
After installing latex-suite, every time I open a .tex file, whether it's from gVim or terminal vim, whether it contains a \begin statement or not, Vim immediately crashes.
After repeatedly making it crash I was able to read a Python Traceback string in the status line, which mentioned line 530 in C:\Python27\lib\site.py (which only contains known_paths = addusersitepackages(known_paths)), but the rest of the traceback is not viewable since the statusline display truncates it and this only appears for a moment anyway before automatically crashing.
Is there a way I could capture this Traceback output in a more permanent and complete way, along with how things go from this plugin to Python, etc.?
(I tried the -V15filename.log option but it's (as usual) useless, containing some partial log upto an ancient point in the vim startup process.)
Edit: Apologies for not mentioning the OS previously (other than indirectly through the C:\ path), this problem is on Windows. And from the other linked question it seems like almost everyone who tries latex-suite on Windows runs into this problem.
Update: Just a FTR - setting verbosefile doesn't help (presumably because the writes are buffered per the doc), and :redir doesn't capture this either, ends with whatever operation happened before this error and crash.
OK, I put here as an answer.
This answer could be kind of work around for solving your latex plugin problem in windows vim. However if your question sticks to "getting error message before crashing" , it may not give you help. I don't have much experience with windows OS.
Latex Suite plugin uses python to generate some formatted text. It could bring better performance. However the plugin provides no-python ways for that as well, to let user without installing python runtime or with very old python version use the plugin too.
Since you mentioned that your problem was in python codes. You can try disabling python in that plugin, and test if the performance was acceptable.
The plugin provided a variable for that, you could add this line in your vimrc
let g:Tex_UsePython=0
Nice to see it helped.
Did you try to run with redirected stderr?
vim file.tex &> errors.log
or
vim file.tex 2> errors.log
1) If you are able to compile Vim from the source (using MinGW as you are on Windows), you could run it with gdb. Then you could set some breakpoints/check the stack trace until you detect a line near the crash. The instructions to run Vim with the gdb and read the stack traces are found in :help debug-gcc.
At the end of that help file (:help get-ms-debuggers) you can find instructions on how to obtain some debug tools for Windows.
These tools can be used on the following alternatives, explained in detail on :help debug-win32:
2) In case you didn't compile Vim, obtain the debug symbols (PDB), which should be available from the same place that you obtained the executable. Attach Visual Studio to the Vim process, reproduce the crash, then read the stack trace through Visual Studio's dialog reporting the crash.
3) Same as 2) but using WinDbg instead of Visual Studio.
4) Inspect the Minidump file, in case your crash generate one. In addition to the referenced help section, you may find useful information on the following links:
Where to find mini dmp files in windows 7
How to read the small memory dump file
In case you are on a computer running linux, did you try saving the strace output in a file?
strace gvim -V9log.txt file.tex > stdout.txt 2> stderr.txt
And then having a closer look at the output files, especially the last 10-100 lines? I am not sure if it will capture the system calls of the plugins though, but it could be a starting point.
I somehow cannot get the TeX-PDF plugin to compile the files appropriately. It states in the plugin description that it defaults ot pdflatex, which I have on my Windows 7, it is mapped in the path variable. It spits out the error:
compiled with errors
which is baically an undefined case (there are no errors in the file, it compiles with pdflatex from the cmd well).
I tried almost all of the solutions for VIM (like vim-latex, atp, etc) but I can't get them to work with pdflatex. I just want to be able to avoid the process in the command line. I need a step by step, or really well explained guide, because I am sick of reading all the manuals from top to bottom, and not having a result.
If you
:set shellcmdflag=/k
any external shell command invoked from Vim will keep the console window open. You'll see the exact command-line that the plugin uses to compile, and can investigate from there what's wrong. Once you've found the problem, you need to "work backwards" to see how you can get the fix into the plugin; maybe there's a setting to influence the compilation. (I don't know / use the plugin myself.)
I switched to Vim from Textmate a while back but I miss the Actionscript bundle for Textmate—particulate the ability to compile Actionscript directly from Textmate.
Has anyone found a way to compile Actionscript directly from Vim?
Yes, compiling AS3 from Vim is very easy.
One basic way, assuming you have main.as file open and you are in --NORMAL-- mode, type this:
:!/path/to/flex45/bin/mxmlc %
to obtain main.swf file next to main.as or:
:!/path/to/flex45/bin/mxmlc -output=../deploy/%<.swf %
to obtain ../deploy/main.swf (relative to main.as).
! means "the following is a shell command".
% means "this file, here, in the current buffer".
%< means "this file's name without the point and the extension".
Obviously it's not really smart but you can make mxmlc read a configuration XML, for more control. See the Flex doc for the list of possible arguments. Using this way it's going to suck a lot to debug your builds.
Another way is to set mxmlc as the build program for actionscript files with:
set makeprg=/path/to/flex45/bin/mxmlc
Then, type :make % to build your project. Errors will be displayed in the quickfix window.
That said, the actual "programming" part of doing AS3 with Vim sucks hard because the only omni-completion script available (to my knowledge) has been very very limited and unfinished for years (it's not an attack against the author which must be praised for his efforts).
I've started to augment that script a couple of months ago but it's far from being finished (and a low level priority) and not that good anyway compared to what you may get in Flash Builder or FDT.
Actually, the AS3 bundle is the only thing I miss from my TextMate days, it was surprisingly polished.
In the official vim documentation, there is an topic called: "fcsh tools : you can compile .as and .mxml files from vim via fcsh : Flex Comipler SHell". That topic describe all process of compilation .as and .mxml, but as noticed there, it tested only on unix systems.
If you want to use FCSH on vim, take a look on https://github.com/lucasdupin/vim-utils/blob/master/bin/fcshd - it works exactly like the FCSH daemon you have on TextMate.
I'm a VIM noob, and have revisited it time and again, and I'm hoping to actually stick with it this time. Primarily I'm programming in TextMate with Ruby on Rails. On advice from someone, I have installed Janus (https://github.com/carlhuda/janus) and its helping a lot. But one thing I miss is having a "project" so that I can easily get back into a project quickly.
I want to be able to start a copy of macvim, pointing it to a file, or giving it a command, to load a project back to where I last left it. This means:
CD to the root of the project
Set back up any tabs / splits I had set, at their same locations
Reopen the files I was working on last.
I'm going to explore Conque Shell today (http://code.google.com/p/conque/) and if that works, I would want those shells to also reload and fire off their startup commands. (CD to the project root, fire up the rails server, tail a log, etc.)
Suggestions? I'm looking to streamline my process so that I can just click a shortcut or run a command and after a few seconds be staring at my dev environment right where I left it last.
Bonus: I often use windows too, so being able to do the same in GVim would be great as well.
Thanks for your help
You may want to check out Vim's built-in ability to create a restore sessions. These allow you to save pretty much everything you have setup including cwd, folds, splits, buffers, vars etc. See :help :mksession.
Here are two plugins that help with saving and restoring sessions:
sessionman: http://www.vim.org/scripts/script.php?script_id=2010
session.vim: http://www.vim.org/scripts/script.php?script_id=3150
You might also want to check out the project plugin: http://www.vim.org/scripts/script.php?script_id=69
I too have heard good things about rails.vim.
For Rails developer, there is a well-known plugin by Tim Pope named rails.vim.
Once you are at the root of a rails project (You can change Vim current directory with :cd /path/to/project/root ), rails.vim provides quick way to access your file like :
:Rcontroller file
:Rview file
:Rstylesheet file
They are other options to refactor using partials. Install it and type :help rails.txt. There is plenty of nice features like that. It is really useful to speed up access to your project files.
You can probably combine it with session.vim which provides a way to restore your previous session automatically.
If you don't want to type the path of your project, one possible solution, is to add at the end of your .vimrc the following code :
if isdirectory("~/workspace/project1")
cd ~/workspace/project1
endif
This way you always start Vim into your current workspace. Obviously if you need to switch to another directory you have to manually edit your .vimrc... which is kinda sub optimal.
Terminitor (a Ruby Gem) won't specifically solve your vim "project" goal, but it will solve the rest of your problems. You can setup your terminal windows and then execute a command to capture the terminal positions and sizes, edit the configuration to add any other commands (in Ruby) that you want executed and this will allow you to restore your environment.