You are not logged in.

#1 2010-10-24 03:55:00

frabjous
Member
Registered: 2010-07-13
Posts: 367

LaTeX composition in (g)vim with live update-as-you-type PDF preview

Ever since I tried the gummi LaTeX editor, I've been intrigued by the idea of having a live-updating PDF preview--i.e., a PDF output panel which updated as I typed. This provides all the good things of WYSIWYG, but without taking away the control I have by editing the source directly. However, apart from its preview panel, I was thoroughly unimpressed with gummi as an editor. It had none of the advanced features I was used to.

Since then, I've been trying various techniques to make it work with my preferred editor, (g)vim. At first, I used latexmk with the -pvc option which recompiles whenever the file changes, along with a PDF editor that refreshes whenever the file changes (like evince); but found it slow and tended to get stuck.

My current method is to use mupdf as my viewer, with a custom LaTeX script which calls xdotool to update mupdf whenever I have a successful compilation. This seems to be working fairly well.

Here's an animated GIF screen capture showing it in action

There is typically still a 1-second delay between typing something and it showing on the PDF preview, but it's not really any worse than it seems to be wih gummi, and I get to use a world-class editor.

I should note that I'm not using the vim-latex suite plugin or anything similar, so I don't know whether or not any of this is compatible.

Anyway, I thought I'd post my method here just in case anyone thought it useful, or more importantly, anyone had any feedback for how it might be improved. I'm not a programmer (--my degrees are in philosophy!--) and don't really have that much experience with vim or bash scripting, so forgive my naive methods.

Anyway, in my ~/.vim/ftplugin/tex.vim I have:

" Function to save, check if already compiling and compile if not
function! KKLtxAction()
    " go to right directory
    lcd %:p:h
    " save the file if need be and it's possible
    if filewritable(bufname("%"))
        silent update
    endif
    " see how many kkltx processes there are
    " note that there are always 3 when the checking itself happens
    " so we need there to be no more than that
    let numrunning = system("ps ax | grep kkltx | wc -l")
    if numrunning < 4
         exec "silent !kkltx " . expand("%") . " &"
    endif
endfunction
" Call this function whenever mupdf the cursor moves
" But only in gvim
if has("gui_running")
    au CursorMoved *.tex call KKLtxAction() 
    au CursorMovedI *.tex call KKLtxAction()
endif

So whenever the cursor moves, the file saves and checks if the compilation script is running. If it is not, it runs it. Here's the script, named kkltx. (To make it work, create a ~/.config/kkltx folder. Sorry about the stupid name; I needed it to be uncommon.)

#!/bin/bash
file="$1"
logfile="${file%.tex}.log"
auxfile="${file%.tex}.aux"
# check to see when file was last saved and
# check see what version of file was last compiled
currmodified=$(stat -c %Y "$file")
oldmodified=$(cat $HOME/.config/kkltx/lastprocessedfile)
# if they're the same exit with no change
if [ "$currmodified" == "$oldmodified" ] ; then
    echo "nochange"
    exit 0
else
    # if compilation is necessary, check what program to use
    # 'xelatex' should appear in first 5 lines for xelatex docs
    if head -n 5 "$file" | grep -i -q 'xelatex' > /dev/null 2>&1 ; then
        execprog="xelatex"
    else
        execprog="pdflatex" 
    fi 
    # try to compile
    if ${execprog} -interaction=batchmode -file-line-error -synctex=1 "$file" > /dev/null 2>&1 ; then
       # if compiling worked check if bibtex needs to run
       if cat "$logfile" | grep -i -q 'undefined citations' > /dev/null 2>&1 ; then
          if bibtex "$auxfile" > /dev/null 2>&1 ; then
               if ! ${execprog} -interaction=batchmode -file-line-error -synctex=1 "$file" > /dev/null 2>&1 ; then
                    echo "failure"
                    exit 1
               fi
          else 
                echo "bibfail"
                exit 2
          fi
       fi
       # check if a rerun is necessary to update cross-references
       if cat "$logfile" | grep -i -q 'rerun to get' > /dev/null 2>&1 ; then
               if ! ${execprog} -interaction=batchmode -file-line-error -synctex=1 "$file" > /dev/null 2>&1 ; then
                  echo "failure"
                  exit 1
               fi
       fi
       # update mupdf by sending the r key to it
       xdotool search --class mupdf key --window %@ r > /dev/null 2>&1
       echo "success"
       # save time of compilation
       echo -n "$currmodified" > "$HOME/.config/kkltx/lastprocessedfile" 2>/dev/null
    else
       echo "failure"
       exit 1
    fi
fi
exit 0

One thing you miss out on with mupdf is the SyncTeX ability in, e.g., TeXworks that allows you jump from the source to the corresponding part of the PDF and vice-versa. Here's a kludge that at least gets to you to the right page by using xdotool to send the signal to move to a certain page matching the source, or to read what page mupdf is on, and move to the beginning of the source code for that page (or strictly, a couple inches over and down). Again, in my ~/.vim/ftplugin/tex.vim

" \v to open the viewer
nnoremap \v :exec "silent! !mupdf ".expand("%:r").".pdf &"
" forward search with mupdf
function! MuPDFForward()
    " make sure I'm in the right directory
    lcd %:p:h
    let pageforward = 0
    " find where I am now; adjust for starting with 0
    let searchline = line(".") + 1
    let searchcol = col(".") + 1
    " use synctex to find the page to jump to
    let pageforward = system("synctex view -i " . searchline . ":" . searchcol . ":\"" . expand("%") . "\" -o \"" . expand("%:r") . ".pdf\" | grep -m1 'Page:' | sed 's/Page://'")  
    " if a page other than 0 is found, send the page number to mupdf
    if pageforward > 0
        call system("xdotool search --class mupdf type --window %1  \"" . pageforward . "g\"")
    endif
endfunction
" inverse search with mypdf
function! MuPDFReverse()
    lcd %:p:h
    let gotoline = 0
    " call a script which returns the line number near start of page shown on mupdf
    let gotoline = system("syncreverse-mupdf.sh " . expand("%:p:r"))
    if gotoline > 0
        exec ":" . gotopage
    endif
endfunction
" mappings \f and \r for forward and reverse search
nnoremap <buffer> \f :call MuPDFForward()<CR>
nnoremap <buffer> \r :call MuPDFReverse()<CR>

Here is the script syncreverse-mupdf.sh called by the above:

#!/bin/bash
# syncreverse.sh full-path-of-PDF-minus-extension
pathfn="$1"
# reduce filename to base, add .pdf
pdffile="$(echo "$pathfn" | sed 's@.*/@@g').pdf"
# change to directory containing files
cd "$(echo "$pathfn" | sed 's@\(.*\)/[^/]*@\1@g')"
# read page number in mupdf window title
page=$(xdotool search --class mupdf getwindowname | sed 's:.* - \([0-9]*\)/.*:\1:')
# synctex lookup; remove junk
line=$(synctex edit -o "$page:288:108:$pdffile" | grep -m1 'Line:' | sed 's/Line://' | head -n1)
line=$(echo "$line" | sed -n 's/\([0-9]*\).*/\1/p')
# return line for gvim
echo "$line"
exit 0

I also recommend putting mappings in vim to send keys to mupdf to move around, so you can move around in the preview but without making (g)vim lose focus. These are just examples.

nnoremap <silent> <buffer> <C-PageDown> :silent! call system("xdotool search --class mupdf key --window %@ Page_Down")<CR>
nnoremap <silent> <buffer> <C-PageUp> :silent! call system("xdotool search --class mupdf key --window %@ Page_Up")<CR>

Anyway, these could definitely be improved, by, for example, accommodating master/sub-documents, and so on. Thoughts?

Last edited by frabjous (2010-11-04 22:41:21)

Offline

#2 2010-10-24 11:51:34

keenerd
Package Maintainer (PM)
Registered: 2007-02-22
Posts: 647
Website

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

This is great.  I was trying to hack on Gummi to get Vim into it, but this is a good bit lighter.  Also, props for mupdf, a very fine choice.

You need a name (though kkltx is good enough) and an AUR package.  (Though I'll glady do the packaging part.)

edit:  Might want to use some pid files.  Interesting things could happen if you have another doc open with mupdf.  And it is better than continually pgrepping.

Last edited by keenerd (2010-10-24 12:30:12)

Offline

#3 2010-10-24 14:46:24

frabjous
Member
Registered: 2010-07-13
Posts: 367

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

You need a name (though kkltx is good enough) and an AUR package.  (Though I'll glady do the packaging part.)

I was going to wait until I had it a bit more fine tuned. I've done some very simple AUR packaging, but I'd appreciate whatever help I could get.

edit:  Might want to use some pid files.  Interesting things could happen if you have another doc open with mupdf.  And it is better than continually pgrepping.

I really only use mupdf for this purpose, especially since it can't print. But I'd love to see some suggestions for improvement. I've been using linux less than a year, bash for only a few months, and again, I'm not a programmer, and know relatively little about what can be done with pids, etc. If you have specific suggestions, please let me know.

Offline

#4 2010-10-24 16:22:06

keenerd
Package Maintainer (PM)
Registered: 2007-02-22
Posts: 647
Website

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

This one is not tricky to install, but people are lazy.   You'll get more testers :-)

I use Mupdf as my default viewer, since it loads so fast.  I have three open right now.

A pid file is a unique file that contains the pid of a running process.  So you only ever have one process* (don't start a new one if the file exists) and you can always access the process (read the file) without mixing it up for another.

*Though I'd recommend using "mktemp" instead of a fixed name.  That way you can have multiple instances of kkltx.

Here is an example:  http://www.odi.ch/weblog/posting.php?posting=291

The magic bit is "$!", which gets the pid of the last backgrounded process.

Last edited by keenerd (2010-10-24 16:23:54)

Offline

#5 2010-10-25 00:26:49

medonja
Member
Registered: 2010-08-31
Posts: 10

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

This sounds wonderful! Thank you frabjous! I take it said "update per changed character" feature from vim could not be made to work in geany?

Offline

#6 2010-10-25 02:03:00

frabjous
Member
Registered: 2010-07-13
Posts: 367

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

keenerd wrote:

This one is not tricky to install, but people are lazy.   You'll get more testers :-)

Understood, though it'll mean learning more than I currently know about installing vim scripts in the vim directories rather than the user directories.

A pid file is a unique file that contains the pid of a running process.  So you only ever have one process* (don't start a new one if the file exists) and you can always access the process (read the file) without mixing it up for another.

*Though I'd recommend using "mktemp" instead of a fixed name.  That way you can have multiple instances of kkltx.

Here is an example:  http://www.odi.ch/weblog/posting.php?posting=291

The magic bit is "$!", which gets the pid of the last backgrounded process.

Thanks. That does look interesting. I'll have to think about how to implement it though. I doubt it'll work just the same to have vim launch something in the background and then have vim echo $! back to itself--I imagine vim's own system calls would end up launching other things in the background in the mean time, though I'd have to test it to find out. If that doesn't work, there would probably have to be an intermediate script that did this recording and checking and only launched the main script if the pid last recorded has finished.

I can't understand how I'd make use of mktemp, though. There would be no way (... short of doing the same kind of thing we're trying to avoid...) of passing the temporary name from one instance of the script to another. I suppose I could use a single script that ran in a loop instead of one that ran whenever the cursor moved. But that's back to more or less how latexmk worked, and I would always forget to stop it, and I'd find it still running two days later...

I can't imagine a scenario in which you'd need to have multiple files compiling at once. As is, you can have multiple LaTeX files open at once; it's just that when you switch from one to the other, the new one will always compile as soon as it can, even if it hasn't been changed. The script updates all instances of mupdf after a successful compile.

This sounds wonderful! Thank you frabjous! I take it said "update per changed character" feature from vim could not be made to work in geany?

I only used geany once for about 10 minutes. I really don't know enough about it. I believe you can write plugins for it, and so long as you could write a plugin that saved the file an initiated an external script whenever the cursor moved, the method could probably be adapted.

Last edited by frabjous (2010-10-25 02:04:03)

Offline

#7 2010-10-25 11:29:40

keenerd
Package Maintainer (PM)
Registered: 2007-02-22
Posts: 647
Website

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

frabjous wrote:

Understood, though it'll mean learning more than I currently know about installing vim scripts in the vim directories rather than the user directories.

Head over to the AUR and see how those vim plugins work.

frabjous wrote:

I doubt it'll work just the same to have vim launch something in the background and then have vim echo $! back to itself--I imagine vim's own system calls would end up launching other things in the background in the mean time

I am pretty sure processes don't work that way.  They are reasonably seperated and generally don't step on each other's toes.  Everything uses pid files and I've never heard of this happening.

frabjous wrote:

I can't understand how I'd make use of mktemp, though. There would be no way (... short of doing the same kind of thing we're trying to avoid...) of passing the temporary name from one instance of the script to another.

Fair enough, don't worry about mktemp yet.  (There are ways around it, but probably not worth the effort.)  A fixed pid file for mupdf would be more practical.

Offline

#8 2010-10-25 20:35:56

frabjous
Member
Registered: 2010-07-13
Posts: 367

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

keenerd wrote:

I am pretty sure processes don't work that way.  They are reasonably seperated and generally don't step on each other's toes.  Everything uses pid files and I've never heard of this happening.

It isn't a matter of stepping on each other's toes. It's a matter of "$!" being available inside vim. I've been testing it, and system("echo $!") inside vim never seems to yield anything at all, even if vim has just launched something in the background.

You could have vim call an intermediate script, however, which, in turn, launched something else and then recorded $!. In fact, I have a working version of the script that does that rather than prepping to see if the compilation script is still running and it seems to be working fine. I'm not really sure, however, whether that approach is better than simply creating a "lock" file which is checked and prevents other occurrences of script from running when found, which is created when the script starts and removed when it ends.

Fair enough, don't worry about mktemp yet.  (There are ways around it, but probably not worth the effort.)  A fixed pid file for mupdf would be more practical.

I thought the point of working with pid's was to remove the need for grepping the results of ps when deciding whether or not to start a new compilation. That check has to happen a lot more often than sending the r key to mupdf. Right now, the 'r' key is sent to every open mupdf window when any successful compilation takes place. It's hard to imagine a situation in which that would be terribly harmful. (Even if you had several open, refreshing others would typically do nothing.) Is the advantage supposed to be speed? It would also be easy to have xdotool check the name of the pdf in the mupdf window title and only send 'r' to that one. But I guess it wouldn't be hard to record the pid when mupdf first starts. I'd be surprised if it made any real difference though (--mupdf is so fast that I've never noticed any delay at all in updating it--), and it would mean that it wouldn't work unless mupdf was started from inside vim.

I'll whip up a new version and see if it seems any faster.

(P.S. After playing around for a little while, it looks like the Window IDs used by xdotool are different than the pid's of the processes to which they belong. It would probably make more sense to record the window ID.)

Last edited by frabjous (2010-10-25 20:47:29)

Offline

#9 2010-10-25 21:31:49

brisbin33
Member
From: boston, ma
Registered: 2008-07-24
Posts: 1,796
Website

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

As another option (I don't do latex all that often but this works really well for me):

Use zathura as your PDF viewer; it will automatically refresh if the PDF source it's viewing is changed. Then just tell vim to recompile on save like so:

~/.vimrc

command! Reload :! (pdflatex % &>/dev/null) &
au BufWritePost *.tex silent Reload

I also have an open command I can call when I first start:

command! Open   :! (file="%"; pdflatex "$file" $>/dev/null && zathura "${file/.tex/.pdf}" &>/dev/null) &

Both of these are purposely output-suppressed because I kept getting staircased output bleeding into my vim session... oh well.

If compilation fails, the pdf just doesn't update. I have yet-another macro to compile and actually show the output so that I can see what's wrong and fix it.

Offline

#10 2010-10-28 03:27:06

frabjous
Member
Registered: 2010-07-13
Posts: 367

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

brisbin33 wrote:

Use zathura as your PDF viewer; it will automatically refresh if the PDF source it's viewing is changed. Then just tell vim to recompile on save like so:

I've tried that. Zathura is considerably slower than MuPDF, and so it didn't work as well for this, and secondly, if the PDF becomes damaged or missing, it stops auto-updating, which is extremely annoying if you're constantly re-compiling. Another advantage of MuPDF is that it shows the page number in the title bar, which allows for a kind of kludgy inverse synctex search using xdotool. I did get something like that working with Zathura at one point (the scripts are in the thread), but it required closing Zathura and reopening it to read the last location from the saved bookmarks.

command! Reload :! (pdflatex % &>/dev/null) &
au BufWritePost *.tex silent Reload

My script automatically handles BibTeX when needed (at least if natbib is used), allows for synctex forward searches and file:line:error handling, which this doesn't. Plus, you have to do the saving manually to trigger the compilation. Mine saves for you, and compiles for you.

Both of these are purposely output-suppressed because I kept getting staircased output bleeding into my vim session... oh well.

You added a "silent" there, so I don't think it should. But you could add another silent before the ! too to be sure.

If compilation fails, the pdf just doesn't update. I have yet-another macro to compile and actually show the output so that I can see what's wrong and fix it.

The version of the script will have a command that will show the output of the previous compile and jump to the first line with an error if there was an error. That's all compatible with doing what you do as well -- I just didn't want to include it here: Unix philosophy of just sticking to one task, and all that...

I'm working on slightly revised version with a PKGBUILD. It should be done soon.

Last edited by frabjous (2010-10-28 03:29:52)

Offline

#11 2010-10-28 04:47:06

frabjous
Member
Registered: 2010-07-13
Posts: 367

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

OK, I've uploaded a PKGBUILD to AUR. Since I've changed how it handles recognizing when it's safe to recompile, it no longer needs to have a weird name. The name is now:

vim-live-latex-preview

It comes with a very short vim help file, which I'll copy here.

*live-latex-preview.txt*    For Vim version 7.3.  Last change: 2010 Oct 27

                                                            *live-latex-preview*
A plugin for creating a live-updating PDF 
 preview for a LaTeX file in MuPDF

Default key bindings:~

\p = Begin auto-compilation and launch MuPDF preview.
\o = End auto-compilation and close MuPDF preview.
\s = Check the result of the last compilation; 
       jump to first error in case of errors.
\f = Forward search to page in PDF matching cursor 
       position in source. 
\r = Reverse/inverse search to position in source
       matching active page in MuPDF. (Very approximate.)

\<PageUp>, \<PageDown>, \<Up>, \<Down>, \<Right>, \<Left>, \G
    \m, \t, \-, \+, \= = Send the corresponding keystrokes
    to the MuPDF preview without losing focus on vim Window

The '\' can be changed by changing <LocalLeader>.

Be aware that your file is saved whenever the cursor moves. Be sure
to take the appropriate measures to keep back-up saves and undo files
so you can undo changes if need be.

To compile with XeLaTeX rather than PDFLaTeX, include the string 
'xelatex' somewhere in the first five lines of your file (e.g., in a
comment). Currently only PDFLaTeX and XeLaTeX are supported. (Support 
for LuaLaTeX and/or LaTeX > dvips > ps2pdf may be added in the future, 
but they may be too slow for the live updating process anyway.)

The plug-in does not currently support master- and sub-documents
via LaTeX's \input{...} and \include{...} mechanisms. This may be
added in the future.

 vim:tw=78:ts=8:ft=help:norl:

This is a new version; pretty much completely rewritten from the above. In particular, I've tried to incorporate keenerd's ideas; in particular some changes:

  • Rather than grepping the active processes, when it begins a compilation, it records the process ID of the compilation script, and will not begin a new compilation until that process finishes.

  • When it first launches MuPDF, it records the Window ID and sends it back to vim, so vim knows which instance of MuPDF to refresh or work with.

  • I've added a \s quick key which provides a one-word summary of the effects of the last compilation and jumps to the line number of the first error, if there were errors.

  • The script is located in a separate file in the main $VIMRUNTIME/ftplugin folder, rather than a user's tex.vim file.

I'm sure there's still plenty of room for improvement. I'd still like to get it to handle master/sub-documents well, for example. All comments welcome.

Offline

#12 2010-10-28 16:40:40

je
Member
Registered: 2010-10-28
Posts: 1

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

The compilation is not incremental, so that if you have a long document that loads a lot of packages the delay will be substantial, right?

Offline

#13 2010-10-28 16:47:30

frabjous
Member
Registered: 2010-07-13
Posts: 367

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

The compilation is just normal compilation, so for a long or complex document, it could be a lot slower, yes.

I wouldn't really trust the results of an incremental compilation for LaTeX, personally (if it's even possible... there is the preview package, but I haven't looked much into it.)

Offline

#14 2010-10-28 17:37:40

SleepyFloyd
Member
Registered: 2008-06-11
Posts: 91

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

That's a pretty cool  project.

I'm writing my Master thesis right now, which is ~120 pages at the moment, with ~500 footnotes and 12 pages of bibliographical entries. Using it on an I3 530. the preview isn't really "live", but lags a few seconds behind. No problem for me, just wanted to give some feedback.

I guess you can't really use it with bigger LaTeX projects anyway, as you'd usually use your "main.tex" only to source your chapters. I got only 6 lines in my document space, \inputing the chapters. Unfortunately, the preview doesn't work if your document is set up that way.
But it's great to quickly test a few things and compare results in realtime. Very handy.

Offline

#15 2010-10-28 18:14:29

frabjous
Member
Registered: 2010-07-13
Posts: 367

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

SleepyFloyd wrote:

I guess you can't really use it with bigger LaTeX projects anyway, as you'd usually use your "main.tex" only to source your chapters. I got only 6 lines in my document space, \inputing the chapters. Unfortunately, the preview doesn't work if your document is set up that way.

I do hope to allow for that in a future version of the script. I don't think it'll be too hard to implement. I just wanted to put something up on AUR to get some feedback on the overall process before trying to complicate things.

Offline

#16 2010-10-28 20:34:45

meinhimmel
Member
Registered: 2007-07-12
Posts: 58

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

I changed around brisben33's lines to work for me:

" LaTeX Live Preview
"--------------------------------
autocmd FileType tex silent :! (file="%"; pdflatex % &>/dev/null && zathura "${file/.tex/.pdf}" &>/dev/null) &
command! Reload :! (pdflatex % &>/dev/null) &
au BufWritePost *.tex silent Reload

Offline

#17 2010-10-29 06:17:45

frabjous
Member
Registered: 2010-07-13
Posts: 367

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

I've just uploaded version 0.2 of my scripts to AUR.

Highlights:

  • Subdocuments (using \input{..} and \include{...}, etc.) are now (mostly) supported. This requires placing a comment of the form:

    % !TeX root = main.tex

    in the first five lines of the included document to use the preview while editing it, so that it knows what file to compile. Change "main.tex" to the appropriate filename. (They should all be in the same directory.) The only important part is "root = ..." . The "!TeX" part is meant for compatibility with TeXworks and other editors that use a similar mechanism.

  • A minor bug sometimes preventing the preview from starting if the PDF file didn't already exist has been fixed.

  • An autocommand now automatically jumps the preview to the page being editing when vim's insert mode is entered.

  • An updated help file. (You may need to delete "live-latex-preview.tex" from $HOME/.vim/doc if you had the previous version installed; it is safe to delete this even after the new version is installed.)

(There are also some more tiny improvements.)

Offline

#18 2010-10-29 06:47:16

Army
Member
Registered: 2007-12-07
Posts: 1,784

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

I have to try this, looks very interesting, especially because I'll have to write quite a bunch of things in LaTeX the next months.

Offline

#19 2010-11-01 20:31:53

guga31bb
Member
Registered: 2010-11-01
Posts: 19

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

This is probably my fault, but I can't get this to work. I installed the package with yaourt and opened a latex file but can't get it to do anything. Do I have to activate it somehow? What is <LocalLeader> and how do I change it? These things are probably obvious but I can't find any direction in the help file.

Offline

#20 2010-11-01 21:07:10

frabjous
Member
Registered: 2010-07-13
Posts: 367

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

guga31bb wrote:

This is probably my fault, but I can't get this to work. I installed the package with yaourt and opened a latex file but can't get it to do anything. Do I have to activate it somehow? What is <LocalLeader> and how do I change it? These things are probably obvious but I can't find any direction in the help file.

Assuming you haven't changed LocalLeader (See below), you should be able to start the preview by loading your .tex file in vim and type in (in normal mode):

\p

(I.e., backslash followed by p. one after another. Don't try to type them at the same time, and don't do it in insert mode: that'll put \p into your document.)

I would have hoped that that was pretty clear from the help file.

To close the preview, type \o (again in normal mode).

You can change the keybindings for the preview by changing LocalLeader. See

:help Leader

inside vim for more info. However, if you want to change LocalLeader, put something like:

let maplocalleader = "_"

in your .vimrc. Then the keybinding for the plugin would start with _ rather than \. E.g., _p would begin the preview, and _o would end it. This just gives you some more customizability in how the plugin works. The newer version of the help file should explain how you can disable the default key mappings so you can create your own entirely, as well.

Offline

#21 2010-11-01 21:26:52

guga31bb
Member
Registered: 2010-11-01
Posts: 19

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

Thank you for the response -- I know basic vim teaching probably isn't what you signed up for so I appreciate your help. Your program looks really cool so I'm determined to get it working! However, I still can't get it to do anything. I tried changing the mapleader (let maplocalleader = "_") and pressing _p, but all it does is paste (regardless of what I choose for mapleader).

I also tried :help live-latex-preview and was shown "Sorry, no help [...]". Does that mean I didn't install correctly? Or am I just really slow? sad

Offline

#22 2010-11-01 21:36:11

frabjous
Member
Registered: 2010-07-13
Posts: 367

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

Sounds to me like the plugin is not being loaded at all.

Try putting:

filetype on
filetype plugin on

in your .vimrc. Without that, no plugins related to filetypes will be loaded.

Also, do your LaTeX files use a .tex extension? The plugin expects a .tex extension, and won't work with anything else.

If you don't mind using \ instead of _ there shouldn't be any need to do anything with maplocalleader.

Last edited by frabjous (2010-11-01 21:37:59)

Offline

#23 2010-11-01 22:13:35

guga31bb
Member
Registered: 2010-11-01
Posts: 19

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

Woo! Your filetype* lines did the trick.

One last question -- while I type, my cursor is constantly followed by "success" or "failure". Is that supposed to happen? (it's kind of distracting)

Thanks for you work. This is a great project!

Offline

#24 2010-11-01 23:02:24

frabjous
Member
Registered: 2010-07-13
Posts: 367

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

guga31bb wrote:

One last question -- while I type, my cursor is constantly followed by "success" or "failure". Is that supposed to happen? (it's kind of distracting)

No, it shouldn't. That appears to be a bug, which I'll have to look further into. I think it only happens in regular vim, and I've mainly been testing in gvim, which is why I haven't noticed it before. You might try using gvim until I can figure it out.

Offline

#25 2010-11-01 23:28:50

frabjous
Member
Registered: 2010-07-13
Posts: 367

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

All right, I think I figured it out. I'm posting a new version to AUR now.

There's also a slight improvement for automatic interaction with BibTeX even when natbib is not used.

Let me know if you find any more problems like that. It is very helpful.

Offline

Board footer

Powered by FluxBB