vim-latex-devel

[Vim-latex-devel] New compiler features!

[Srinath A. <sr...@fa...>]

Hello,

Two new features have been added to latex-suite:

1. Generating certain output formats correctly by automatically
   compiling multiple times. This is a feature which has been mostly
   picked up from tex-tools.vim by Luc Hermitte and massaged
   stylistically and otherwise to fit nicely in with the rest of
   latex-suite. Also, if python is available, then it will use python
   instead of vimscript for certain functions which enable it to be
   faster and also avoid opening unused buffers.

http://vim-latex.sourceforge.net/documentation/latex-suite/compiling-multiple.html

2. Automatically handling format dependencies: For example, if you
   generate pdf documents by first compiling to dvi, then to ps, then to
   pdf, then latex-suite handles it automatically, if you specify
   a setting
   g:Tex_FormatDependency_pdf = 'dvi,ps,pdf'

http://vim-latex.sourceforge.net/documentation/latex-suite/compiler-dependency.html

The latest beta containing the 2 features is available at:

vim-latex.sourceforge.net/download/latexSuite-multicompile.tar.gz

This is a release from the latex-multi-compile branch in the latex-suite
CVS tree. Those interested can directly get it from there. Any feedback
is appreciated. I am aiming at merging these changes into the main trunk
wihin the next week.

Thanks,
Srinath

Re: [Vim-latex-devel] New compiler features!

[Srinath A. <sr...@fa...>]

On Thu, 28 Aug 2003, Srinath Avadhanula wrote:

> Two new features have been added to latex-suite:
>
I incorporated both these features into the main trunk, because
I beleive that both these features are pretty "safe", i.e will not break
the original functionality.

The latest developement release on the latex-suite download page
contains these additions.

Srinath

Re: [Vim-latex-devel] New compiler features!

[Luc H. <her...@fr...>]

Hello,

* On Thu, Aug 28, 2003 at 04:38:03PM -0700, Srinath Avadhanula <sr...@fa...> wrote:
> 2. Automatically handling format dependencies: For example, if you
>    generate pdf documents by first compiling to dvi, then to ps, then
>    to pdf, then latex-suite handles it automatically, if you specify a
>    setting g:Tex_FormatDependency_pdf = 'dvi,ps,pdf'
> http://vim-latex.sourceforge.net/documentation/latex-suite/compiler-dependency.html


I read on this page:
> let g:Tex_CompileRule_dvi = 'latex --interaction=nonstopmode $*'
> let g:Tex_CompileRule_ps = 'dvips -Ppdf -o $*.ps $*.dvi'
> let g:Tex_CompileRule_pdf = 'ps2pdf $*.ps'

I'd rather use definitions like:
  let g:Tex_CompileRule_tex_dvi = 'latex --interaction=nonstopmode $*'
  let g:Tex_CompileRule_dvi_ps = 'dvips -Ppdf -o $*.ps $*.dvi'
  let g:Tex_CompileRule_ps_pdf = 'ps2pdf $*.ps'

Why ? Because we may prefer to use systematically pdflatex, but
sometimes, for some documents, we may be interrested in ps2pdf because
some particular packages, like pst-uml, are not compatible with
pdflatex.

So, we may want to bind <c-l>P to tex-[pdflatex]->pdf and <c-l>pdf to
tex->ps->pdf. This way, we have the choice to use one approach or the
other at the last moment, with no need to redefine 4 global variables.

> The latest beta containing the 2 features is available at:
> http://vim-latex.sourceforge.net/download/latexSuite-multicompile.tar.gz

I had never spent much time on what &efm should be for makeindex or
bibtex. So, you may need to eventually have a look at this issue.

-- 
Luc Hermitte
http://hermitte.free.fr/vim/

Re: [Vim-latex-devel] New compiler features!

[Srinath A. <sr...@fa...>]

On Fri, 29 Aug 2003, Luc Hermitte wrote:

> I read on this page:
> > let g:Tex_CompileRule_dvi = 'latex --interaction=nonstopmode $*'
> > let g:Tex_CompileRule_ps = 'dvips -Ppdf -o $*.ps $*.dvi'
> > let g:Tex_CompileRule_pdf = 'ps2pdf $*.ps'
>
> I'd rather use definitions like:
>   let g:Tex_CompileRule_tex_dvi = 'latex --interaction=nonstopmode $*'
>   let g:Tex_CompileRule_dvi_ps = 'dvips -Ppdf -o $*.ps $*.dvi'
>   let g:Tex_CompileRule_ps_pdf = 'ps2pdf $*.ps'
>
> Why ? Because we may prefer to use systematically pdflatex, but
> sometimes, for some documents, we may be interrested in ps2pdf because
> some particular packages, like pst-uml, are not compatible with
> pdflatex.
>
I actually gave those examples of g:Tex_CompileRule_format somewhat
redundantly. I assume that most people will be using the same rule on
most files. If someone does want to change the way compilation is done
on a particular file/project, then he can always use the .latexmain way
to redefine things within a certain directory. For example, the
.latexmain file could contain

let g:Tex_FormatDependency_pdf = 'dvi,ps,pdf'
let g:Tex_CompileRule_pdf = 'ps2pdf $*.ps'

in one directory and

let g:Tex_FormatDependency_pdf = 'pdf'
let g:Tex_CompileRule_pdf = 'pdflatex --interaction=nonstopmode $*'

in another. Better still, you could make a file called pst-uml in the
latex-suite/packages directory which contains something like:

let g:Tex_FormatDependency_pdf = 'dvi,ps,pdf'
let g:Tex_CompileRule_pdf = 'ps2pdf $*.ps'

This way a file which uses the pst-uml package automatically uses the
longer route while the others use the faster route.

Anyway, I did consider your way of doing it. But after some
consideration also of factors like backwards compatibility, I decided
that since I could do everything which I could forsee with the current
method, why change things?

> So, we may want to bind <c-l>P to tex-[pdflatex]->pdf and <c-l>pdf to
> tex->ps->pdf. This way, we have the choice to use one approach or the
> other at the last moment, with no need to redefine 4 global variables.
>
I prefer using \ll for compiling into everything and just changing
settings on a per-directory basis. I have always been a fan of
polymorphic keys...

> > The latest beta containing the 2 features is available at:
> > http://vim-latex.sourceforge.net/download/latexSuite-multicompile.tar.gz
>
> I had never spent much time on what &efm should be for makeindex or
> bibtex. So, you may need to eventually have a look at this issue.
>
Yes... Should remember to put this on the TODO list.

-- 
Srinath