Showing posts with label backward search. Show all posts
Showing posts with label backward search. Show all posts

Saturday, December 29, 2007

PDFSync Inverse Searches in MacVim

Remember the post on doing inverse searches in Vim on OS X? The idea was to drop gvim-pdfsync into
/usr/local/bin
(or somewhere else in your PATH) and then execute
gvim-pdfsync "%file" %line
to do inverse searches in Vim for OS X just like you can in Windows or in other UNIXes. For example, in Skim, under the PDFSync section of the Sync tab of the Preferences, you can put
Preset: Custom
Command: gvim-pdfsync
Arguments: "%file" %line

For MacVim

I thought it might be nice if I published how to do the same thing in the nascent MacVim, which supports servers just like Vim for Windows. Provided that you've installed the mvim shell script somewhere in your PATH, you can setup Skim with
Preset: Custom
Command: mvim
Arguments: --remote-tab-silent +":%line;foldo!" "%file"

or, if you don't like tabs
Preset: Custom
Command: mvim
Arguments: --remote-silent +":%line;foldo!" "%file"

Retro-Approach

Alternatively, if you really liked the gvim-pdfsync approach and want something similar for mvim, put mvimtab-pdfsync or (if you don't like tabs) mvim-pdfsync in your PATH (e.g., in /usr/local/bin) and then setup Skim for:
Preset: Custom
Command: mvimtab-pdfsync
Arguments: "%file" %line

or (if you used mvim-pdfsync)
Preset: Custom
Command: mvim-pdfsync
Arguments: "%file" %line
I hope that helps.

Wednesday, July 25, 2007

VIM-LaTeX Modification: Forward Searching in OS X

UPDATE 3: If it doesn't seem like commands are launching from within Vim, check out my post on setting PATH in Vim. In particular, if you are using the nascent MacVim, checking the "Launch Vim processes in a login shell" preference may fix your problems.

UPDATE 2: I've updated the patch file to fix a few bugs in my original implementation (thanks to Ross M. Richardson for the help!). This version supports forward searching from multi-file projects. By the way, if you didn't know, if you have a project with multiple files where the main LaTeX document is called my_latex_file.tex, you should create a dummy file called my_latex_file.latexmain in the same directory. That way, VIM-LaTeX will know to run its compiler and viewer on the main file and not on any of the smaller constituent files.

UPDATE 1: Skim 0.6 and up supports spell checking of a PDF. This is a strange feature of a PDF viewer since Skim does not allow you to edit the PDF text directly. However, it makes a lot of sense when inverse searches are supported. After doing Shift+Command+CLICK on the misspelled word, the TeX editor will open up near the line of TeX where the word is found.

I have already commented on doing inverse searches (or backward searches) in Vim on OS X. However, I have not handled forward searches. Ross M. Richardson offers a hack for doing forward searches into PDFView; however, it's clear that while this is a hack it is certainly not a lifehack. What I really want is a version of VIM-LaTeX that supports using PDFView, Skim, TeXniscope, or any UNIX shell script as a forward-search-compatible viewer.

The script I presented in an earlier post makes backward searches compatible in nearly any PDF/DVI viewer. Now, I just need to hack compiler.vim to do the reverse. I did this by modifying the Tex_ViewLaTeX and Tex_ForwardSearchLaTeX functions from the 20060325 release of VIM-LaTeX. You can find my changes in VIM-LaTeX-osx-inverse-search-compiler.patch. To apply the patch, go into your ~/.vim/ftplugin/latex-suite/ directory, backup your old compiler.vim file, and try
patch -p0 < VIM-LaTeX-osx-inverse-search-compiler.patch
Of course, you should either drop the patch file into that directory or change the patch command so it has the full path to the patch. Now, all you need to do is configure your ~/.vimrc and you'll be able to use \lv for viewing and \ls for forward searches.

OS X Applications: Say that I want to use Preview to view PostScript files, TeXniscope to view DVI files, and Skim to view PDF files (note that both TeXniscope and Skim can open all of these, but only TeXniscope supports DVI source specials). In that case, I could put these lines in my ~/.vimrc file:
let g:Tex_ViewRule_ps = 'Preview'
let g:Tex_ViewRule_pdf = 'Skim'
let g:Tex_ViewRule_dvi = 'TeXniscope'
Now, VIM-LaTeX will use these whenever \lv (for viewing) or \ls (for forward search) are used. That's right, it will do forward searches with these OS X applications (well, Skim and TeXniscope)! That's easy enough.

UNIX Viewer Scripts: Now, let's say I wanted to use the skim and texniscope scripts that I built earlier. In this case, I use the following in my ~/.vimrc file:
let g:Tex_TreatMacViewerAsUNIX = 1
let g:Tex_ExecuteUNIXViewerInForeground = 1
let g:Tex_ViewRule_ps = 'skim'
let g:Tex_ViewRule_pdf = 'skim'
let g:Tex_ViewRule_dvi = 'texniscope'
That g:Tex_TreatMaxViewerAsUNIX tells VIM-LaTeX not to use open -a to open the viewer. The g:Tex_ExecuteUNIXViewerInForeground gets rid of the & appended to the end of the execution strings used by VIM-LaTeX. For some reason, this option needs to be set to get UNIX viewers to work in MacVim.

Empty Viewer Scripts and Other Stuff: As before, if those ViewRule variables are set to empty values (i.e., ''), open -a will be used. On the other hand, if g:Tex_TreatMacViewerAsUNIX is set, VIM-LaTeX will act like it does on a UNIX machine, and xdvi, xdvik, and kdvi can be used. These three DVI viewers are handled specially. Any other UNIX script should follow the convention:
script "%target_file" %line "%source_file"
where script is the UNIX command, %target_file is the main PDF, PS, or DVI file to open, and %line is the line in the TeX source file %source_file for forward searching (i.e., using \ls). If \lv is being used, the %line and %source_file parts are omitted.

Wednesday, July 11, 2007

PDFSync inverse searches on Vim for OS X

FINAL UPDATE: See the new post, "PDFSync Inverse Searches in MacVim," for the state of the art on this subject.
UPDATE 8: Skim 0.6 and up supports spell checking of a PDF. This is a strange feature of a PDF viewer since Skim does not allow you to edit the PDF text directly. However, it makes a lot of sense when inverse searches are supported. After doing Shift+Command+CLICK on the misspelled word, the TeX editor will open up near the line of TeX where the word is found.

UPDATE 7: caveat Vimmer! Inverse searches in Skim are called up with Shift+Command+CLICK. This is fine; however, if you hold Shift+Command too long, the AppleScript for calling up Vim is going to get confused. In other words, be sure to release the modifier keys as soon as possible after the "click."

UPDATE 6: I found information about doing both forward and backward searches with Vim and PDFView (see also: using gotoline.sh). From these, I've made hacks to the VIM-LaTeX scripts for PDFView and other viewers (like Skim and TeXniscope). I will describe these hacks in another post.

UPDATE 5: See Vim Tip #225 and the corresponding wiki entry for information about both backward and FORWARD searches in Vim. I also found a nice LaTeX tools script for Vim that has forward searching built in. I found these pages linked from a page on xdvi inverse searches.

UPDATE 4: Very trivial updates have been made in a 1.03 version of this script.

UPDATE 3: I have posted a 1.02 version of this script. The changes are fairly trivial, but you might be interested in checking it out.

UPDATE 2: This script is now a part of the Skim wiki.

UPDATE 1: I have mirrored this post at my web site.

WINDOWS USERS: See "Performing inverse searches" from the VIM-LaTeX quick start guide.

I have posted information about this in a number of places [1, 2, 3, 4, 5]. I plan to add something at MacResearch sometime soon too.

The package PDFSync allows users to do "backward searches" or "inverse searches" from PDF viewers like iTeXMac, TeXniscope, Skim, and others. That is, if you generate a PDF with LaTeX (or Plain TeX or ConTeXt), you will be able to click on text in the PDF and have an editor open up and position the cursor at the TeX source code that generated that text. That can be very nice.

There is a related feature for DVI files, but there are very few good DVI viewers out there (TeXniscope comes close), so I just focus on PDFSync).

I use Vim with VIM-LaTeX to do my document preparation. I would like to also be able to use PDFSync. However, while inverse searching is supported in Windows, it is not easily done in OS X.

I found a thread describing how to do inverse searching with AppleScript that issues raw commands to Vim. I decided to take that AppleScript, package it into a bash script, and fix it so that it had no problem handling files with spaces or symlinked files or multiple files with the same base name. The result is this script:
#!/bin/bash

filename="$1"
lineNum="$2"

[ "${filename:0:1}" == "/" ] || filename="${PWD}/${filename}"

exec osascript \
-e "set ESC to ASCII character of 27" \
-e "tell application \"Vim\" to activate" \
-e "tell application \"System Events\"" \
-e "tell process \"Vim\"" \
-e "keystroke ESC & \":set hidden\" & return " \
-e "keystroke \":if bufexists('$filename')\" & return " \
-e "keystroke \":exe \\\":buffer \\\" . bufnr('${filename}')\" & return " \
-e "keystroke \":else \" & return " \
-e "keystroke \": edit ${filename// /\\\\ }\" & return " \
-e "keystroke \":endif\" & return " \
-e "keystroke \":${lineNum}\" & return " \
-e "keystroke \"zO\" " \
-e "end tell" \
-e "end tell"
Copy that script in a place (preferably in your PATH) like
/usr/local/bin/gvim-pdfsync
and chmod it 0755. That is, do
chmod 0755 /usr/local/bin/gvim-pdfsync
Then you can use the script like
gvim-pdfsync "%file" %line
where %file is the name of the file to be opened and %line is the line to place the cursor on. So, for Skim, you would put in your LaTeX (or Sync) preferences under "PDFSync" support:
Preset: Custom
Command: gvim-pdfsync
Arguments: "%file" %line
After configuring Skim, BE SURE TO CLICK AWAY FROM THE TEXT BOXES before closing the configuration. For example, click on one of the other tabs. Otherwise, the dialog box may not record your changes to the last text box you changed.

I hope that's useful to someone.