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.
Related
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 a very specific issue but, based on what I've seen online, a surprisingly common one. I'm on a rather old version of Scientific Linux 5, which is based on Red Hat. I use vim with the Solarized vim color scheme, and my TERM environment variable is usually set to xterm-256color. This worked fine until I started using tmux. On non-empty lines in vim, the color scheme only extended to the end of the document's characters, the remaining whitespace being plain back background.
The stock fix for this in online guides is to set TERM='screen-256color'. However, upon doing this I would get the ominous warning: WARNING: terminal is not fully functional - (press RETURN), when trying to do innocuous things like read man pages. However, everything seemed to be working fine, and the Solarized bug was fixed.
I've found a functional fix - using TERM='xterm-256color' by default and adding this line to my .bashrc:
alias v='function _vim(){ TERM='screen-256color'; vim $1; TERM='xterm-256color'; };_vim'
but it seems like a hack. Anecdotally, I've also set alias tmux='tmux -2', which is a common suggestion with color-scheme-related issues.
I also know that the terminfo screen-256color is available on my machine.
So, really, the main befuddling thing is that, when using TERM='screen-256color', I'm getting those warnings about full functionality when nothing seems to be wrong.
I don't have root access, so ideally any fix suggestions wouldn't need that.
EDIT: I should mention that TERM='screen-256color-bce' gave the same problems as TERM='screen-256color'.
The user's environment is not specified, but likely using bash and less (Scientific Linux 5 does not have more).
The package list on Scientific Linux 5's ftp site, shows ncurses-5.5-24.20060715.src.rpm, which does not include screen-256color (it was added to ncurses in October 2006). That system might have the later terminal database by some post-install change.
An application using termcap would not see this terminal description. Scientific Linux's bash and less programs could have used termcap rather than terminfo. A quick check of the changelog for bash-3.2-21.el5 says
* Fri Feb 1 2008 Miroslav Lichvar <mlichvar#redhat.com> - 3.2-21
- Link with libtermcap
On some systems, a missing termcap entry will cause a warning. But with Scientific Linux 5, the given warning message comes from less, which checks its terminal description (using the termcap interface), to ensure that it can clear the remainder of the current line, the remainder of the screen and the entire screen.
In Scientific Linux 5, the less package is built with ncurses. A problem with less using TERM=screen-256color would be one of these possibilities
the screen-256color entry is not really installed, or
there is some problem with the termcap interface provided by ncurses.
While there were ongoing performance-fixes for the screen program around this time, the former seems the more likely, as seen in this discussion of a poorly-written entry for screen-256color in early 2006: Re: screen-256color terminfo entry?. What I get from reading this is that there was some poorly-written terminal description (not part of ncurses) which produced the problem. By the time it was proposed for inclusion in ncurses (October 2006), the problem had been repaired. In any case, it would have been corrected at that 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'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.