[Vim-latex-devel] Re: Review of vim-latex status

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

Hi,

* On Tue, Dec 24, 2002 at 01:11:30PM -0800, Srinath Avadhanula <sr...@fa...> wrote:
> Things which need to improve
> ============================
> 1. Atleast for me, the diacritics have been a longstanding source of
>    annoyance at unexpected times. Everytime I try doing a=b, I get
>    a\'{b}. And assignments like a=b are so common that this becomes
>    painful pretty fast. I would love to find out a better way to
>    implement support for diacritics. I am in fact thinking of disabling
>    diacritics by default unless we get some better ideas.

AFAIK, "a\'b" is valid, and most LaTeX implementations now support
8-bits characters. I.e.: I never write "\'e" (nor the ugly "\'{e}")
anymore, but simply "é". The diacritics stuff is useless to me, even
when I write documents in French. I'd rather type one more key when I
need to enter expanded diacritics like \oe -- since then, I added a more
logical digraph for oe (œ) into vim.
The format used by (La)TeX is very simple and logical.

> Future Directions
> =================
> These are things which are on my "cool things to do" list. Please feel
> free to share your own.

> 1. Dependency checking: i.e, when the user chooses the 'pdf' format,
>    latex-suite automatically compiles the dvi file, converts to ps and
>    then to pdf according to user preferences. I know that lh-tex (by
>    Luc) already has these kind of things implemented. 
>
>    But from what I can see, he has hardcoded the dependencies, i.e pdf
>    always follows from ps and things like that. I would think that we
>    could have options like

Yes and No.
The dependencies are indeed hardcoded, but I propose to ways to produce
the pdf file: thanks to (e)pdf(la)tex, or thanks to ps2pdf following a
first convertion done with 'dvips -Ppdf'.

I'd rather have both possibility beeing directly available (ie two
different mappings) from vim without having to change even only one
option.

> 	   Tex_FormatDepenency_pdf = 'ps'
> 	   Tex_FormatDepenency_ps = 'dvi'
> 	   Tex_FormatDepenency_dvi = 'tex'
>    which enable a customized dependency setting. 

I don't know if we can be that generic...

>    I propose that we have a discussion about the best way to implement
>    this. (Luc can start by telling us how he did it). 

...I already tried to factorize all common transformations into
sub-functions. The result is:
- s:Make() that runs ':make' (and saves vim-options before changing
  them, echoes different things, and checks for errors)
  Note: this is a low level function used by the TKMake{*}file()
  functions.
- s:CheckDeps() that checks dependency issues between two files (which
  one is newer than the other), and runs the proper s:TKMake{ext}file()
  function if needed.

- s:TKMakeDVIfile() : implements the main loop that converts .tex files
  into .dvi or .pdf. It also run bibtex, makeindex, etc if needed
- s:MakePdfTeXfile(...) <=> call <sid>TKMakeDVIfile((a:0>0)?(a:1):5, "pdf")
- s:TKMakePSfile() : implements the transformation .dvi->.ps
  does some other common things, _and_ checks weither we must use the
  -Ppdf option or not (according to the parameters passed). 
- s:TKMakePDFfile() : implements the transformation .ps->.pdf

You proposed to merge all the TKMake{*}file() functions into one. I fear
the result will be too complex because: 
- the transformation .tex->* is not like the other transformations
  (latex may have to be run three times or more, bibtex and makeindex
  may be used, etc)
- the tranformation .dvi->.ps checks one little parameter


What can be done is to have one dependencies engine (DE) that uses the
options you proposed, and the various TKMake functions. With a
registering facility, the DE could be extended with new functions
(because tomorrow, we rather produce an XMLfo document before the final
pdf -- odd idea, but we never know).
I'm not sure it is so important.

BTW: I have some similar functions to launch the various viewers.

>    Since this is (will be) such a core part of latex-suite,
>    I would like this to be implemented after a lot of thought.

> 2. Compilation Sequence: Again, Luc has implemented a way to run latex,
>    bibtex, makeindex etc according to what needs to be run etc. 

I don't deserve all the credits. The initial version is from Tomer Kol
(that why many function-names start with TK).

> 3. New developer: Becase Luc has implemented both 1 and 2 in lh-tex, I
>    propose that we get Luc into the developer team if he wants. To
>    start with, he can implement his ideas on a seperate branch.
>    Afterwards, we can merge this into the main trunk.

Why not. I won't have so many time to spend on the project, but I will
be glad to parcipate.
But beware, I have many, many ideas with some of them implemented in
completly different ways than the ones you choose for latex-suite.

> 4. Citation browser: I know that auctex from emacs has a feature where
>    it sets up a browsable window of the citations found in the bibtex
>    file. We could implement a system where if the user presses <Alt-c>,
>    \cite{} is inserted and the browser comes up asking him to choose a
>    citation.

Nice idea.

> 5. Removal of unwanted cruft: I am pretty sure latex-suite has features
>    which it can afford to lose.

6. Sometimes, I'd like some feedback about the last improvments I made
   in mu-template. But before, I must found some time to finish to write
   the documentation and to definitively fix the funky-characters issue.
   The big last improvment concerns the possibility to hit for instance:
   '\tab^R<SPACE>' which pops up a dialog box asking for which
   template-file we wish to expand (here: tabular, tabeqnarray, etc)

> Happy Holidays!!! (My girlfriend is dragging me off to some shopping
> now)
:-)

Happy holidays.

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