vim-latex-devel

[Vim-latex-devel] compiler rules

[Benji F. <be...@me...>]

      I have a headache!

      Here is the current state of affairs.  When latex-suite/main.vim 
is called, the following things happen (details edited out):

* :source compiler.vim
*	:fun! SetTeXCompilerTarget()
*	:com! TCTarget :call SetTeXCompilerTarget()
* :fun! <SID>SetTeXOptions()
*	:setlocal sw ts isk
(This step should be deleted, but that is not today's headache.)
*	:TCTarget
*	:runtime compiler/tex.vim
* :call <SID>SetTeXOptions()

The net effect is that compiler/tex.vim is sourced after 
SetTexCompilerTarget() is called, so the compiler script sets 'makeprg'.

      At Srinath's request, I have uncommented the "runtime 
compiler/tex.vim" line; I commented this out in a revision a few days ago.

      If you guys trust me, I will make radical changes at some point. 
For now, my goal is to undo the damage I did, and maybe make a small 
improvement.  (My new setting for 'makeprg' works on more systems, I 
think.)  I have tested this on Linux, W95, and OSX.  (On OSX, it is a 
problem that compiler/tex.vim ignores the target format, since most 
users want pdf instead of dvi.)

      One thing I cannot figure out:  on W95, g:Tex_CompilerFormat is 
defined, and I cannot figure out where.  This variable is used in 
compiler/tex.vim and overrides all other methods.

					--Benji

Re: [Vim-latex-devel] compiler rules

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

On Fri, 8 Nov 2002, Benji Fisher wrote:

>       I have a headache!
>
But its worth it :) The compiler rule thing seems to be working quite
nicely now... Agreed that there is all sorts of wierd program flow as
you point out in the next para, but at least as of now, its working
well, even if a little unoptimally.. If you want go ahead and change
things around so that only compiler/tex.vim defines 'makeprg'.

> think.)  I have tested this on Linux, W95, and OSX.  (On OSX, it is a
> problem that compiler/tex.vim ignores the target format, since most
> users want pdf instead of dvi.)

Hmmm.... This will be on my todo list. I assume on yours as well.. It
will be easy enough to check g:Tex_DefaultTargetFormat there...

>       One thing I cannot figure out:  on W95, g:Tex_CompilerFormat is
> defined, and I cannot figure out where.  This variable is used in
> compiler/tex.vim and overrides all other methods.
>
Thats totally bizzare. I dont get this behavior on my win2k box. Also
I did the following in the CVS repository:

.vim > fgrep Tex_CompilerFormat `find . -print` 2>/dev/null

and the only files this finds is compiler/tex.vim, where it occurs as:

VIM> " If the user wants a particular way in which the latex compiler needs to be
VIM> " called, then he should use the g:Tex_CompilerFormat variable. This variable
VIM> " needs to be complete, i.e it should contain $* and stuff.
VIM> if exists('g:Tex_CompilerFormat')
VIM> 	let &l:makeprg = current_compiler.' '.g:Tex_CompilerFormat

Are you sure about this?

-- 
Srinath

[Vim-latex-devel] Re: compiler rules

[Hermitte L. <her...@fr...>]

* On Fri, Nov 08, 2002 at 04:18:28PM -0800, Srinath Avadhanula <sr...@fa...> wrote:
> > think.)  I have tested this on Linux, W95, and OSX.  (On OSX, it is a
> > problem that compiler/tex.vim ignores the target format, since most
> > users want pdf instead of dvi.)

Or may be just check tex-tools.vim + compiler/tex.vim (my variation of
a former Srinath's file) + vim-tex.sh
I already manage that and much more.

The dependancies for several compilation chains are managed, and the
compilation done.
    tex-->dvi-->ps ; 
       latex + dvips 
    tex-->pdf ; 
       pdflatex
    tex-->dvi-->ps-->pdf
       latex + dvips -Ppdf  + pspdf
Plus support of bibtex and makeindex if needed.
[The user can also choose pdftex, etex, epdflatex, ...]

This should save you the headache.
BTW, since our last conversation (Srinath), now I support your
{project}.latexmain *and* g:TexFile (from TKlatex).

-- 
Luc Hermitte

Re: [Vim-latex-devel] Re: compiler rules

[Benji F. <be...@me...>]

Hermitte Luc wrote:
> * On Fri, Nov 08, 2002 at 04:18:28PM -0800, Srinath Avadhanula <sr...@fa...> wrote:
> 
>>>think.)  I have tested this on Linux, W95, and OSX.  (On OSX, it is a
>>>problem that compiler/tex.vim ignores the target format, since most
>>>users want pdf instead of dvi.)
>>
> 
> Or may be just check tex-tools.vim + compiler/tex.vim (my variation of
> a former Srinath's file) + vim-tex.sh
> I already manage that and much more.

      The real problem is how to do it in the current structure of latex 
suite, and how that structure should be improved.

> The dependancies for several compilation chains are managed, and the
> compilation done.
>     tex-->dvi-->ps ; 
>        latex + dvips 
>     tex-->pdf ; 
>        pdflatex
>     tex-->dvi-->ps-->pdf
>        latex + dvips -Ppdf  + pspdf
> Plus support of bibtex and makeindex if needed.
> [The user can also choose pdftex, etex, epdflatex, ...]

      Does that mean that you run latex; latex; bibtex; latex if 
necessary?  (Or is is latex; bibtex; latex; latex ?)

					--Benji

[Vim-latex-devel] Re: compiler rules

[Hermitte L. <her...@fr...>]

* On Sat, Nov 09, 2002 at 12:36:01AM -0500, Benji Fisher <be...@me...> wrote:
> >The dependancies for several compilation chains are managed, and the
> >compilation done.
> >    tex-->dvi-->ps ; 
> >       latex + dvips 
> >    tex-->pdf ; 
> >       pdflatex
> >    tex-->dvi-->ps-->pdf
> >       latex + dvips -Ppdf  + pspdf
> >Plus support of bibtex and makeindex if needed.
> >[The user can also choose pdftex, etex, epdflatex, ...]
>      Does that mean that you run latex; latex; bibtex; latex if 
> necessary?  (Or is is latex; bibtex; latex; latex ?)

I check the main loop for tex->dvi/pdf ...

1- if there exist a .idx file, makeindex is run, (a backup for the old
one beeing made)
2- On the first passage in 2-, if there is '\bibdata' in the .aux file,
   bibtex is run 
3- if is there exists a .bbl file, it is backuped
4- run e\=\(pdf\)\=\(la\)=tex
5- same as 2-
6- checks if the .log file ask for a rerun (not always correctly
   working) and check if the .idx has changed ; if either requires it,
   goto 1-

hum... may be I should delete 2- and change 6- to check the need of
re-running based of bibtex changes.

-- 
Luc Hermitte

Re: [Vim-latex-devel] Re: compiler rules

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

On Sat, 9 Nov 2002, Hermitte Luc wrote:

> > > think.)  I have tested this on Linux, W95, and OSX.  (On OSX, it
> > > is a problem that compiler/tex.vim ignores the target format,
> > > since most users want pdf instead of dvi.)
>
> Or may be just check tex-tools.vim + compiler/tex.vim (my variation of
> a former Srinath's file) + vim-tex.sh I already manage that and much
> more.
>
compiler/tex.vim has changed since then. It no longer requires
vim-tex.sh because I found out a way to take care of badly nested '(' in
the LaTeX output. It looks like vim can indeed handle two stack
operations based on a single line of compiler output... I have this
thing written down in some cvs log (maybe on my local cvs repository).

This next thing of automatically handling dependencies is a nice
thing... I will take a look at it. But looking at another persons code
and then figuring out what part of it overlaps with existing portions,
extracting the necessary stuff etc takes a while. The fastest way by far
of getting things into LaTeX-suite will be to maybe attach exactly one
file which I can directly read in into some part of LaTeX-suite.
However, please dont take this to mean that I (or the other developers)
will never look at the code. It just means that it will take a lot
longer because it will get put on someones todo list.

Thanks,

Srinath


-- 
Srinath Avadhanula
Nov 9 12:24am
"It's a summons."
"What's a summons?"
"It means summon's in trouble."
		-- Rocky and Bullwinkle

[Vim-latex-devel] Re: compiler rules

[Hermitte L. <her...@fr...>]

* On Sat, Nov 09, 2002 at 12:33:41AM -0800, Srinath Avadhanula <sr...@ee...> wrote:
> > Or may be just check tex-tools.vim + compiler/tex.vim (my variation
> > of a former Srinath's file) + vim-tex.sh I already manage that and
> > much more.
> compiler/tex.vim has changed since then. It no longer requires
> vim-tex.sh because I found out a way to take care of badly nested '('
> in the LaTeX output. 

I've seen that later, but wasn't sure whether the outgoing messages from
LaTeX were still "reformatted". Now I  know, cool!

> This next thing of automatically handling dependencies is a nice
> thing... I will take a look at it. 
>
> But looking at another persons code and then figuring out what part of
> it overlaps with existing portions, extracting the necessary stuff etc
> takes a while. 

I do completly understand what you mean.

> The fastest way by far of getting things into LaTeX-suite will be to
> maybe attach exactly one file which I can directly read in into some
> part of LaTeX-suite.

To use my system, we need:
- change your compiler/tex.vim to expose TeXSetEFM (needed as in the
  compilation chain I use many programs: bibtex, makeindex, latex, ...).
  TCLevel is too highlevel there from what I understood.
- change the name of the options I need into my tex-tool.vim ; and
  eventually, split the file to define the options in texrc.vim. [1]
- rework the way I change the shell I'm using on windows boxes.
- 2 other files dedicated to a portable way of manipulating pathnames
  and dependancies.
- change tex-tools to support makefiles if any
- update the way *tex outgoing messages are managed in tex-tools.

> However, please dont take this to mean that I (or the other developers)
> will never look at the code. 
 dont worry :-))


[1] I'd rather have texrc.vim or .texvimrc instead of just texrc
-- 
Luc Hermitte

[Vim-latex-devel] texrc or tex.vimrc or ...

[Benji F. <fis...@bc...>]

Hermitte Luc wrote:
> 
> [1] I'd rather have texrc.vim or .texvimrc instead of just texrc

     On the vim-dev list, I proposed the extension .vimrc .  I am not
sure it is worth changing, though.

     After the stable release, I will have a look at overhauling the
compiler system.

					--Benji

P.S.  Hermite:  I assume you are subscribed to this list, but I want to
make sure before I start removing you from the address list.

[Vim-latex-devel] Re: texrc or tex.vimrc or ...

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

* On Sat, Nov 09, 2002 at 10:49:55AM -0500, Benji Fisher <fis...@bc...> wrote:
> > [1] I'd rather have texrc.vim or .texvimrc instead of just texrc
>      On the vim-dev list, I proposed the extension .vimrc .  I am not
> sure it is worth changing, though.

It is not important. Just a question of taste. As texrc contains VimL,
I'd rather see this fact in its name.

> P.S.  Hermite:  I assume you are subscribed to this list, but I want
> to make sure before I start removing you from the address list.

I am subscribed, Benji.
BTW, You can call me Luc -- hum.. I've some hooks to update, my first
name did not appear in first position on the vim-latex & vim mailiing
lists.

Regards,
-- 
Luc 

Re: [Vim-latex-devel] compiler rules

[Benji F. <be...@me...>]

Srinath Avadhanula wrote:
> On Fri, 8 Nov 2002, Benji Fisher wrote:
> 
> 
>>      I have a headache!
>>
> 
> But its worth it :) The compiler rule thing seems to be working quite
> nicely now... Agreed that there is all sorts of wierd program flow as
> you point out in the next para, but at least as of now, its working
> well, even if a little unoptimally.. If you want go ahead and change
> things around so that only compiler/tex.vim defines 'makeprg'.

      I will, but not before the next stable release.

>>      One thing I cannot figure out:  on W95, g:Tex_CompilerFormat is
>>defined, and I cannot figure out where.  This variable is used in
>>compiler/tex.vim and overrides all other methods.
>>
> 
> Thats totally bizzare. I dont get this behavior on my win2k box. Also
> I did the following in the CVS repository:
[snip]
> Are you sure about this?

      One possibility I will have to check (next time I boot Windows 
...) is that I may have defined this at some point, and it may be saved 
in .viminfo .  At lease, we agree that that part of the code is supposed 
to be skipped (unless the user intervenes).

					--Benji