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.)
Related
I have a make project creating binaries using various back-ends…
→ C, C++, csharp, java… on linux using mono csharp compiler, gcc, etc…
if I choose a single back-end (example csharp) by open a XXX.cs file than the make-output-error parser working OK… this mean error-output is parsed proper and I can jump to the error right away…
if I choose the toplevel make… (open vim without file on a toplevel directory) than the make-output-error parser does not work properly.
I discovered that the vim errorformat variable has changed between 1. and 2.
and now my question: how I can tell vim to recognize the error-output from C,C++,CSharp… and Java during run of the toplevel make ?
Whatever filetype plugin you have for C# is probably changing the value of :help 'errorformat' to work with C# compilers while you are left with the default value when running your top level make which, I assume, outputs errors as-is, without any filtering.
In order for Vim to interpret correctly the potentially mixed output of all your compilers you could:
set errorformat to a value that would work with all those formats,
or add a step to your build process that unifies every native output format into a single format that Vim can interpret without effort.
First option, find the errorformat values used by every compiler and prepend them to the default value at startup:
set errorformat^=<efm for c#>
set errorformat^=<efm for cpp>
...
Second option, I've been thinking for many years about writing a program that would do just that but never found the time to even write a README.md. If such a thing doesn't exist you will have to sed and awk your way on your own I'm afraid.
I'm not sure if this question is appropriate here but I have nowhere else to ask. I recently started to typeset some 'mathsy' stuff using Latex and it became a hobby for me. I've been using TeXnicCenter for this, but feeling that I've got familiar with Latex language, I decieded to improve 'efficiency' of typesetting by changing the editor.
So I decided to use Vim (latest version, 7.4) with Suite-Latex. I've just installed Vim and Suite-Latex, following exactly what was instructed here. I made every necessary changes mentioned here, and it seemed to me that installation was successful (I got what was expected on Step 4)
Then I started to work through this tutorial and everything went fine until this section.
When I press F9 for autoreference, I see that Vim is working on something for split seconds and red error message refering to "can't find [some file name]" in my user/appdata/local/temp directory. The "file name" changes every time I do this (so its kind of temporary file as its directory suggests?). And then it produces a new window with title __ OUTLINE __ where 2 empty lines are showing up.
If I press n (in the new window described above) error message saying "E486: Pattern not found: rf" pops up and pressing j results in going down one row. If I press enter key, message ":call Tex_FinishOutlineCompletion()" pops up.
More frustratingly, if I try to compile a file by entering command \ll, a new window pops up where there are two lines saying:
1.ll I can't find file `newfile.tex'. newfile.tex
2.ll Emergency stop
and below these is a message saying
[Quickfix list]: latex -interaction=nonstopmode -file-line-error-style newfile.tex
So I thought it maybe is something to do with VIM not being able to find files in my computer (so something wrong with grep?), and I tried to resolve it by downloading a software called "cygwin" on which developers said their tests were successful, but it changed nothing.
But I think the two problems are related.
As it is, I am completely newbie in this type of editing environment (or any kind of programming) but I really would like to learn some Vim seeing how efficient it is in typesetting etc. Sorry for not being a pro at typing codes here. Thanks for reading!
I believe you need a latex compiler---I've had this issue and well, one thing that's left out of the conversation a lot is the compiler (pdflatex, latexmk, etc). As of now, you should download a compiler since vim-latex (latex-suite) doesn't actually come with a compiler (that I know of) and it's just a plug in with some cool stuff in it, but not what you need to make a file.pdf out of your file.tex.
It happened to me before. I found out that this problem may happen when you have special characters (such as white space and other symbols) in your file name or folder path. Try again with file name and path only in English letters.
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'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
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.