vim-latex-devel

[Vim-latex-devel] More about F9 completion in multi-directory situation

[Ng Oon-Ee <ng...@gm...>]

In a previous thread I mentioned that using main.latexmain breaks <F9>
completion, where main.tex.latexmain fixes it.

Having used this more in actual writing, I've come across buggy
behaviour while editing subfiles (chap1/chap1.tex for example), where
F9 would give an empty list.

Here's the sequence of events:-

1. Edit chap1/chap1.tex, try F9, doesn't work
2. Edit main.tex, try F9, works
3. Edit chap1/chap1.tex again, try F9, works
4. Try F9 again some time later in chap1/chap1.tex, does not work anymore.

It seems editing main.tex 'caches' the result somehow. If I place
chap1 in the same directory as main.tex there's no problem, but that
simply adds to the clutter (I'm doing a PhD thesis, this thing is
going to grow VERY big esp with all the picture subfolders etc)

Does anyone else on this list have the same workflow as I do
(multi-directory using .tex.latexmain AND uses F9 completion). Ted is
obviously an expert but he doesn't use the feature =).

Re: [Vim-latex-devel] More about F9 completion in multi-directory situation

[Gerd W. <ger...@ma...>]

On Tue, 22 Feb 2011, Ng Oon-Ee wrote:

> In a previous thread I mentioned that using main.latexmain breaks <F9>
> completion, where main.tex.latexmain fixes it.
>
> Having used this more in actual writing, I've come across buggy
> behaviour while editing subfiles (chap1/chap1.tex for example), where
> F9 would give an empty list.
>
> Here's the sequence of events:-
>
> 1. Edit chap1/chap1.tex, try F9, doesn't work
> 2. Edit main.tex, try F9, works
> 3. Edit chap1/chap1.tex again, try F9, works
> 4. Try F9 again some time later in chap1/chap1.tex, does not work anymore.
>
> It seems editing main.tex 'caches' the result somehow. If I place
> chap1 in the same directory as main.tex there's no problem, but that
> simply adds to the clutter (I'm doing a PhD thesis, this thing is
> going to grow VERY big esp with all the picture subfolders etc)
>
> Does anyone else on this list have the same workflow as I do
> (multi-directory using .tex.latexmain AND uses F9 completion). Ted is
> obviously an expert but he doesn't use the feature =).

I think, the problem is that Tex_GetMainFileName() returns

/absolute/path/main

and not

/absolute/path/main.tex


Why do you use 'main.latexmain' and not 'main.tex.latexmain'?
Maybe you can use the variable g:Tex_MainFileExpression, see 
ftplugin/latex-suite/main.vim, function Tex_GetMainFileName(...).


Regards
Gerd

Re: [Vim-latex-devel] More about F9 completion in multi-directory situation

[Ng Oon-Ee <ng...@gm...>]

On Tue, 2011-02-22 at 11:49 +0100, Gerd Wachsmuth wrote:
> > Sorry for being unclear, I was referring in the first paragraph to a
> > bug with using main.latexmain, which I fixed by using
> > main.tex.latexmain.
> >
> > My primary question (the rest of the email) was about a bug I
> > experienced when using main.tex.latexmain.
> 
> I can't reproduce this bug. Maybe you can poste a minimal (not) working 
> example? Maybe this bug is influenced by the settings of the variables 
> Tex_UseOutlineCompletion and Tex_UsePython.
> 
> Regards
> Gerd

Ah, didn't realize my previous email was reply to you only and not to
the list. Added the list back to CC.

Here's my minimal example. There's also a blank main.tex.latexmain.
Instructions at the bottom of the email.

main.tex

\documentclass{report}  
\usepackage{natbib}
\begin{document}
\input{chap1/chap1.tex}
\bibliographystyle{agsm}
\bibliography{thesisrefs}
\end{document}

chap1/chap1.tex

\chapter{Introduction}
\section{First section}

thesisrefs.bib

@techreport{marr_theory_1977,
	title = {A Theory of Human Stereo Vision.},
	author = {D. Marr and T. Poggio},
	month = nov,
	year = {1977}
},
@article{grimson_computer_1981,
	title = {A Computer Implementation of a Theory of Human Stereo Vision},
	volume = {292},
	journal = {Philosophical Transactions of the Royal Society of London.
Series B, Biological Sciences},
	author = {W. E. L. Grimson},
	month = may,
	year = {1981},
	pages = {217--253}
}


INSTRUCTIONS:-

Test 1-
1. edit chap1/chap1.tex
2. Type \cite{ then press F9
3. Should show up as 0 results.
4. Run :edit ../main.tex
5. Type \cite{ then press F9
6. Results show. Undo everything, then :edit chap1/chap1.tex
7. Typing \cite{ then pressing F9 now shows results.

Test 2-
Step 1-4 as above
5. Type \cite{marr then press F9
6. Only one of the two results show. Undo everything,
then :edit /chap1/chap1.tex
7. Typing \cite{ then pressing F9 only shows the previous result (ie.
not both results as in test 1 above)

Re: [Vim-latex-devel] More about F9 completion in multi-directory situation

[Gerd W. <ger...@ma...>]

> INSTRUCTIONS:-
>
> Test 1-
> 1. edit chap1/chap1.tex
> 2. Type \cite{ then press F9
> 3. Should show up as 0 results.
> 4. Run :edit ../main.tex
> 5. Type \cite{ then press F9
> 6. Results show. Undo everything, then :edit chap1/chap1.tex
> 7. Typing \cite{ then pressing F9 now shows results.
>
> Test 2-
> Step 1-4 as above
> 5. Type \cite{marr then press F9
> 6. Only one of the two results show. Undo everything,
> then :edit /chap1/chap1.tex
> 7. Typing \cite{ then pressing F9 only shows the previous result (ie.
> not both results as in test 1 above)

I can't reproduce this. Staying in the main directory, both

gvim chap1/chap1.tex

and

cd chap1/; gvim chap1.tex

does not result in this bug. Which version of the latex-suite do you use? 
What variables do you set?

Regards
Gerd

Re: [Vim-latex-devel] More about F9 completion in multi-directory situation

[Ng Oon-Ee <ng...@gm...>]

On Wed, 2011-02-23 at 08:12 +0100, Gerd Wachsmuth wrote:
> > INSTRUCTIONS:-
> >
> > Test 1-
> > 1. edit chap1/chap1.tex
> > 2. Type \cite{ then press F9
> > 3. Should show up as 0 results.
> > 4. Run :edit ../main.tex
> > 5. Type \cite{ then press F9
> > 6. Results show. Undo everything, then :edit chap1/chap1.tex
> > 7. Typing \cite{ then pressing F9 now shows results.
> >
> > Test 2-
> > Step 1-4 as above
> > 5. Type \cite{marr then press F9
> > 6. Only one of the two results show. Undo everything,
> > then :edit /chap1/chap1.tex
> > 7. Typing \cite{ then pressing F9 only shows the previous result (ie.
> > not both results as in test 1 above)
> 
> I can't reproduce this. Staying in the main directory, both
> 
> gvim chap1/chap1.tex
> 
> and
> 
> cd chap1/; gvim chap1.tex
> 
> does not result in this bug. Which version of the latex-suite do you use? 
> What variables do you set?
> 
> Regards
> Gerd

I'm using a git version, grabbed it on 16th Feb 2011. I've got a fairly
long .vimrc, should I attach it here? My tex.vim is

let g:Tex_DefaultTargetFormat = 'dvi'
let g:Tex_MultipleCompileFormats = 'dvi,pdf'
let g:Tex_ViewRule_ps = 'gnome-open'
let g:Tex_ViewRule_pdf = 'okular'
let g:Tex_ViewRule_dvi = 'okular'
let g:Tex_UseEditorSettingInDVIViewer = 1
let g:Tex_CompileRule_dvi = 'latex -interaction=nonstopmode
--src-specials $*'
let g:Tex_CompileRule_ps = 'dvips -Ppdf -o $*.ps $*.dvi'
let g:Tex_CompileRule_pdf = 'pdflatex -interaction=nonstopmode
-synctex=1 $*'
set iskeyword+=:

Re: [Vim-latex-devel] More about F9 completion in multi-directory situation

[Ted P. <te...@te...>]

> let g:Tex_CompileRule_ps = 'dvips -Ppdf -o $*.ps $*.dvi'

On an unrelated subject, you should probably add -G0 after the -Ppdf...

dvips -Ppdf -G0 -o $*.ps $*.dvi

That will help prevent any problems when converting from CMR fonts to 
Adobe fonts (but the -G0 must come after the -Ppdf).

Additionally, I notice that you do not have a FormatDependency line:

let g:Tex_FormatDependency_ps = 'dvi,ps'

Without that line, if you try to build a ps, the initial dvi will never 
be built.

See

:help compiler-dependency

or search for FormatDependency under:

:help latex-suite

Best --

--Ted

-- 
Ted Pavlic <te...@te...>

Re: [Vim-latex-devel] More about F9 completion in multi-directory situation

[Ng Oon-Ee <ng...@gm...>]

On Wed, 2011-02-23 at 18:39 -0500, Ted Pavlic wrote:
> > let g:Tex_CompileRule_ps = 'dvips -Ppdf -o $*.ps $*.dvi'
> 
> On an unrelated subject, you should probably add -G0 after the -Ppdf...
> 
> dvips -Ppdf -G0 -o $*.ps $*.dvi
> 
> That will help prevent any problems when converting from CMR fonts to 
> Adobe fonts (but the -G0 must come after the -Ppdf).
> 
> Additionally, I notice that you do not have a FormatDependency line:
> 
> let g:Tex_FormatDependency_ps = 'dvi,ps'
> 
> Without that line, if you try to build a ps, the initial dvi will never 
> be built.
> 
> See
> 
> :help compiler-dependency
> 
> or search for FormatDependency under:
> 
> :help latex-suite
> 
> Best --
> 
> --Ted
> 
Thanks Ted, but actually I don't even compile to ps =). dvi for editing,
pdf for final submissions for me.

Re: [Vim-latex-devel] More about F9 completion in multi-directory situation

[Ted P. <te...@te...>]

> Thanks Ted, but actually I don't even compile to ps =). dvi for editing,
> pdf for final submissions for me.

In that case, get rid of the ps compile target. You'll never need it.

(interesting that you never have to worry about the latex vs pdflatex 
image problem... I suppose you always keep a pdflatex-compatible version 
around and a latex-compatible version around manually (I have a Makefile 
that automatically converts as needed))

--Ted

-- 
Ted Pavlic <te...@te...>

Re: [Vim-latex-devel] More about F9 completion in multi-directory situation

[Ng Oon-Ee <ng...@gm...>]

On Fri, 2011-02-25 at 14:31 -0500, Ted Pavlic wrote:
> > Thanks Ted, but actually I don't even compile to ps =). dvi for editing,
> > pdf for final submissions for me.
> 
> In that case, get rid of the ps compile target. You'll never need it.
> 
> (interesting that you never have to worry about the latex vs pdflatex 
> image problem... I suppose you always keep a pdflatex-compatible version 
> around and a latex-compatible version around manually (I have a Makefile 
> that automatically converts as needed))
> 
> --Ted

I always have identically named images, one in eps and another in pdf
(if original file is vector) or png (if original file is raster) in the
same place.

Force of habit, inkscape and gimp are almost always open anyway since my
results are image heavy (computer vision research).