vim-latex-devel — Mailing list for developers/maintainers of the vim-latex project

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

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

Carl Mueller wrote:
[snip]
> In general, we should pay close attention to existing
> packages.  In addition to emacs auctex, there is a related
> emacs package called ultratex.  It has the auctex mappings,
> but also has "lightning completion", which is sort of the
> same thing as word completion with <C-N> or <C-P>.  But you
> do not have the option of rejecting the completion.  This
> never appealed to me, but I know a number of mathematicians
> who like it.  [snip]

      Did you ever try my word_complete.vim script?  It is probably too 
clunky to include with the latex suite, but it was an interesting 
exercise. ;)

http://www.vim.org/script.php?script_id=73

					--Benji

[Vim-latex-devel] More on ultratex

[Carl M. <cm...@ma...>]

I forgot another interesting feature of ultratex.  Typing
<CR> in the middle of a math environment does not break the
line, but takes you out of the current pair of brackets.
This is similar to the current system of <<>>.  This seems
too intrusive to me.  

My own solution to this problem was to use <Alt-F> to take
you to the next pair of brackets.  I bound the <C-F> and
<C-E> keys as in emacs, and these are also useful for
getting out from between brackets.  I'm not saying these are
better than <<>>, which is very elegant.  Of course, there
will always be some times when the user doesn't want to go
to the <<>>.  No system is perfect.  I recommend staying
with <<>>. 

Best wishes,
Carl

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

[Carl M. <cm...@ma...>]

Dear Srinath,

On Sun, Dec 29, 2002 at 07:23:11PM -0800, Srinath Avadhanula wrote:
> I remember that you used the fact that
> amsmath is used to change some behaviors... 

The presence of 

\usepackage{amsmath}

was used for the function key macros for entering
environments, and to replace them.  I picked out the most
common environments in each case (most common for me).  

"  KEY         LATEX                    AMSLATEX
" 
"  F1          equation                 equation
"  F2          \[...\]                  equation*
"  F3          eqnarray                 align
"  F4          eqnarray*                align*
"  F5          asks for environment     asks for environment

For me, the environments are logically ordered in this way,
that is, 

one-line, with numbering
one-line, without numbering
mulitine, with numbering
mulitine, without numbering

Of course, the current scheme of picking out an environment
with a number is nice, too.  The user can always bind the
function keys if he/she wants to save an extra key stroke or 2.
Maybe, the choices presented to the user could depend on the
presence of \usepackage{amsmath}.

In general, I like to use the fewest number of keystrokes.
That's why, for \mathbf, I have the user type a letter and
then press <Alt-b> (which then capitalizes the letter and
encloses it in \mathbf{} ).  Then I realized that with this
method, the same key could be used for several purposes,
depending on the key that preceded it.  For instance, 
<Alt-l> preceded by a bracket inserts \left...\right, but if
it is not preceded by a bracket, it produces \label{}.
Actually, the "smart brackets" were the earliest case of this
that I know of;  These were part of emacs auctex.  

In general, we should pay close attention to existing
packages.  In addition to emacs auctex, there is a related
emacs package called ultratex.  It has the auctex mappings,
but also has "lightning completion", which is sort of the
same thing as word completion with <C-N> or <C-P>.  But you
do not have the option of rejecting the completion.  This
never appealed to me, but I know a number of mathematicians
who like it.  Also, in ultratex, typing $$ results in 
$$

$$
Typing more dollar signs will make the environment cycle
through \begin{equation}...\end{equation}, and so on.  I
decided that it was easier to just get what you want with a
single keystroke, with F1 - F4.

Best wishes,
Carl

Re: [Vim-latex-devel] problem!

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

Hey Fabio,

I have uploaded the "stable" version of dec 13 02 on vim.sf.net. You can
get it from:

vim-latex.sourceforge.net/download/latexSuite-dec-13-02.tar.gz

This uses the "funky" characters like =E4 and =AB etc...  Hope it works...
But before trying it out, could you answer a quick question:

> In fact, I just cannot jump with ctrl-J.
> You can see from my prev. message that <++> are both at the end that in
> the middle of the parenthesis/brackets.

The problem is that IMAP_Jumpfunc() is not able to recognize the <+ and
+> characters as placeholders... Which is really bizzare. After starting
latex-suite, could you on the latest version, try doing

:echo IMAP_GetPlaceHolderStart()
:echo IMAP_GetPlaceHolderEnd()

and see what it says? It should hopefully say '<+' and '+>'. If it
doesn't, then it will be a problem...

Also, it will help greatly if you please spend some time on the newer
version when you get the time.  In particular, if you can:

1. where is your 'encoding', 'fileencoding' etc getting set. Do you set
   values for these anywhere in your .vimrc or ftplugin/tex.vim or even
   in a modeline in your .tex file?

2. What is the value of 'encoding' and 'fileencoding'?

3. Have you changed the value of b:Imap_PlaceHolderStart or
   b:Imap_PlaceHolderEnd or g:Imap_PlaceHolderStart or
   g:Imap_PlaceHolderEnd anywhere (in your .vimrc or ftplugin/tex.vim
   file?) The way imaps is designed, this should not create problems,
   but you never know... If you have changed it, where and to what have
   you changed it?

4. What system are you working on? Is there some special international
   character setting? I tried to reproduce this bug on my win xp box and
   on the vim.sf.net linux shell, but didn't see this problem...

This is quite a serious problem and it will help if we can get it solved
as quickly as possible...

On Mon, 30 Dec 2002, Fabio Spelta wrote:

> Error detected while processing function
> Tex_pack_all..Tex_pack_one..Tex_pack_check..Tex_p
> ack..<SNR>36_GroupPackageMenuItems..Tex_MakeSubmenu..<SNR>36_FilterPackag=
eMenuLHS:
> line    8:
> E121: Undefined variable: s:MenuLHS_enb
> E116: Invalid arguments for function substitute
> E15: Invalid expression: substitute(s:MenuLHS_{commandType},
> '<+replace+>', commandName, '
> g')
>
This was a bug in packages/longtable. I have fixed it...
In the future, packages.vim will handle these things elegantly. Maybe
throw a warning or even just silently ignore things it cannot
understand...

Srinath

Re: [Vim-latex-devel] problem!

[Fabio S. <fab...@ti...>]

 > Whop ?
> 
>       Since the old place holders can cause problems, depending on your 
> encoding, we decided to use the two-character sequences "<+" and "+>" 
> instead by default.  Try banging on <C-J>.


Too bad it does not work.
Here are some messages I got when I launch vim:

Error detected while processing function
Tex_pack_all..Tex_pack_one..Tex_pack_check..Tex_p
ack..<SNR>36_GroupPackageMenuItems..Tex_MakeSubmenu..<SNR>36_FilterPackageMenuLHS:
line    8:
E121: Undefined variable: s:MenuLHS_enb
E116: Invalid arguments for function substitute
E15: Invalid expression: substitute(s:MenuLHS_{commandType},
'<+replace+>', commandName, '
g')      



In fact, I just cannot jump with ctrl-J.
You can see from my prev. message that <++> are both at the end that in
the middle of the parenthesis/brackets.

Can you please upload/send me an older version while you will fix the
trouble? If it is not a trouble to you, it will be great for me: I just
got addicted to vim-latex and while it works this way I cannot use it.



Once again, thank you.




-- 
  Fabio Spelta
  
   email: fab...@ti...
   jabber: fe...@ja...
   ecdl project: http://ecdllibre.sf.net

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

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

Srinath Avadhanula wrote:
> Hello,
> 
> Its been quite a hectic coding time in the vim-latex project and its
> time to step back and take note of all the things which we did/will do.

      This is a useful review.  I am sorry I could not reply sooner.

> 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.

      Yes, this is annoying.  Features should follow the principle of 
least surprise.  They should be off by default if they cause problems 
for anyone:  it is better to require the user to do some work (edit 
texrc, for example) to turn on a useful feature than to force the user 
to twiddle things to get it to work.

      Sooner or later, I plan to have a comprehensive look at texrc: 
put the definition of :TexLet elsewhere, move the documentation into 
doc/latex-suite.txt, review the defaults.  For now, turning off 
diacritics by default is a great first step.

:help design-flexible

> 2. This is as of now, poor documentation at various places. Often times,
>    the script file contains documentation, whereas it should be in a
>    doc/.txt file (in the case of imaps.vim). Sometimes, documentation is
>    just plain missing (in the case of bibtex.vim). I suspect that there
>    are quite a few features of latex-suite even I dont know about.
>    Especially in the case of bibtex.vim, the lack of documentation and
>    menu items etc leads it to be completeley lost to the end-user.
>    Latex-suite really needs some time spent on documentation.

      I give this a very high priority.

:help design-documented

> 3. There are still 'funky' characters in various places of latex-suite
>    leading to internationalization issues.
> 
> 4. Some of the maps do not check for hasmapto(rhs) and mapcheck(lhs)
>    before mapping. This needs to change.
> 
> Future Directions
> =================

      Yup, there is plenty left to do.  ;)

					--Benji

Re: [Vim-latex-devel] problem!

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

Fabio Spelta wrote:
> I converted fileformat of all files in unix, but I got still big
> troubles.
> 
> 
> if i type FIT in insert mode I get
> 
> 
> \textit{<++>}<++>
> 
> And if I type "" I get
> 
> ``<++>''<++>
> 
> Whop ?

      Since the old place holders can cause problems, depending on your 
encoding, we decided to use the two-character sequences "<+" and "+>" 
instead by default.  Try banging on <C-J>.

HTH					--Benji Fisher

[Vim-latex-devel] problem!

[Fabio S. <fab...@ti...>]

I converted fileformat of all files in unix, but I got still big
troubles.


if i type FIT in insert mode I get


\textit{<++>}<++>

And if I type "" I get

``<++>''<++>

Whop ?

Thank you all, too bad I did'nt kept the previous version!

Bye

-- 
  Fabio Spelta
  
   email: fab...@ti...
   jabber: fe...@ja...
   ecdl project: http://ecdllibre.sf.net

Re: [Vim-latex-devel] hm...

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

On Mon, 30 Dec 2002, Fabio Spelta wrote:

> It seems that the latest version was developed in ms-windows... It gives
> lots of errors to me, here are just some of them:
>
Fixed. I uploaded the fixed version. The latest version also contains a
number of other bug fixes.

Srinath

[Vim-latex-devel] hm...

[Fabio S. <fab...@ti...>]

It seems that the latest version was developed in ms-windows... It gives
lots of errors to me, here are just some of them:


Error detected while processing
/home/febs/.vim/ftplugin/latex-suite/packages/graphicx:
line   28:
E15: Invalid expression: ^M
'sbr:Drivers,'^M.'xdvi,'^M.'dvipdf,'^M.'dvipdfm,'^M.'pdftex,'^
M.'dvipsone,'^M.'dviwindo,'^M.'emtex,'^M.'dviwin,'^M.'oztex,'^M.'textures,'^M.'pctexps,'^M
.'pctexwin,'^M.'pctexhp,'^M.'pctex32,'^M.'truetex,'^M.'tcidvi,'^M.'vtex,'^M.'sbr:Rest,'^M.
'debugshow,'^M.'draft,'^M.'final,'^M.'hiderotate,'^M.'hiresbb,'^M.'hidescale,'^M.'unknownk
eysallowed,'^M.'unknownkeyserror'^M
E15: Invalid expression:  ^M
'sbr:Drivers,'^M.'xdvi,'^M.'dvipdf,'^M.'dvipdfm,'^M.'pdftex,'
^M.'dvipsone,'^M.'dviwindo,'^M.'emtex,'^M.'dviwin,'^M.'oztex,'^M.'textures,'^M.'pctexps,'^
M.'pctexwin,'^M.'pctexhp,'^M.'pctex32,'^M.'truetex,'^M.'tcidvi,'^M.'vtex,'^M.'sbr:Rest,'^M
.'debugshow,'^M.'draft,'^M.'final,'^M.'hiderotate,'^M.'hiresbb,'^M.'hidescale,'^M.'unknown
keysallowed,'^M.'unknownkeyserror'^M
line   29:
Not an editor command: ^M
line   62:
E15: Invalid expression: ^M
'sbr:Includegraphics,'^M.'nob:includegraphics,'^M.'spe:height=
,'^M.'spe:width=,'^M.'spe:keepaspectratio=,'^M.'spe:totalheight=,'^M.'spe:angle=,'^M.'spe:
scale=,'^M.'spe:origin=,'^M.'spe:clip,'^M.'spe:bb=,'^M.'spe:viewport=,'^M.'spe:trim=,'^M.'
spe:draft,'^M.'spe:hiresbb,'^M.'spe:type=,'^M.'spe:ext=,'^M.'spe:read=,'^M.'spe:command=,'
^M.'sbr:Rotatebox,'^M.'brs:rotatebox[<++>]{<++>}{<++>},'^M.'spe:origin=,'^M.'spe:x=,'^M.'s
pe:y=,'^M.'spe:units=,'^M.'sbr:Rest,'^M.'brs:scalebox{<++>}[<++>]{<++>},'^M.'brs:resizebox
{<++>}{<++>}{<++>},'^M.'brs:resizebox*{<++>}{<++>}{<++>},'^M.'bra:DeclareGraphicsExtension
s,'^M.'brs:DeclareGraphicsRule{<++>}{<++>}{<++>}{<++>},'^M.'bra:graphicspath'^M
E15: Invalid expression: ^M
'sbr:Includegraphics,'^M.'nob:includegraphics,'^M.'spe:height=
,'^M.'spe:width=,'^M.'spe:keepaspectratio=,'^M.'spe:totalheight=,'^M.'spe:angle=,'^M.'spe:
scale=,'^M.'spe:origin=,'^M.'spe:clip,'^M.'spe:bb=,'^M.'spe:viewport=,'^M.'spe:trim=,'^M.'
spe:draft,'^M.'spe:hiresbb,'^M.'spe:type=,'^M.'spe:ext=,'^M.'spe:read=,'^M.'spe:command=,'
^M.'sbr:Rotatebox,'^M.'brs:rotatebox[<++>]{<++>}{<++>},'^M.'spe:origin=,'^M.'spe:x=,'^M.'s
pe:y=,'^M.'spe:units=,'^M.'sbr:Rest,'^M.'brs:scalebox{<++>}[<++>]{<++>},'^M.'brs:resizebox
{<++>}{<++>}{<++>},'^M.'brs:resizebox*{<++>}{<++>}{<++>},'^M.'bra:DeclareGraphicsExtension
s,'^M.'brs:DeclareGraphicsRule{<++>}{<++>}{<++>}{<++>},'^M.'bra:graphicspath'^M
line   63:
Not an editor command: ^M  

..and so on.

Thank you!

Baibai

-- 
  Fabio Spelta
  
   email: fab...@ti...
   jabber: fe...@ja...
   ecdl project: http://ecdllibre.sf.net

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

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

I personally think that the bracket completion macros are a GREAT idea!

Also, I have tried to implement all the ideas from auctex.vim into the
latest version of latex-suite. I remember that you used the fact that
amsmath is used to change some behaviors... Thats the only thing missing
right now... I will have to take a look at auctex.vim again to see where
you used it...

Srinath


On Sat, 28 Dec 2002, Carl Mueller wrote:

> > I considered the <M-b> mapping for \mathbf{} as my greatest
> > idea,
>
> Sorry, I meant that it WASN'T my greatest idea;  (irony intended).
>
> Best wishes,
> Carl
>

Re: [Vim-latex-devel] Some problems with command implementation

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

On Sun, 29 Dec 2002, Benji Fisher wrote:

> (I was going to say that your command leaves me in Visual mode, not
> Select mode, until I remembered the 'selectmode' option.  Let's wait
> until someone complains, and then modify all our functions to respect
> this one!)

... or we could just document this as a 'feature' ;)

In any case, I guess it works reasonably well now. The easiest way to
insert a \usepackage is just pressing <F5> on an empty line in the
preamble anyway...

Srinath

Re: [Vim-latex-devel] Some problems with command implementation

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

Srinath Avadhanula wrote:

> On Sun, 29 Dec 2002, Srinath Avadhanula wrote:
>
>
> >This works nicely! Thanks!
> >
> >I shall use this idea in packages.vim, templates.vim and
> >custommacros.vim.
> >
>
>
> I see that there's still a problem:
>
> The command:
>
> com! Foo normal! i
>
> doesn't leave the user in insert mode, whereas
>
> com! Foo normal! 0v$
>
> does leave the user in select mode.
>
> This seems to be a vim inconsistency... Any workarounds? Doing a
> startinsert after the command is not going to cut it because sometimes
> we want to end up in insert mode, sometimes in select mode.
>
> Srinath

      I think the idea of "complete command" under :help :normal is that 
you are not allowed to end in Insert mode.  It is inconvenient, but I 
have always been able to work around it.  Of course, I have never tried 
to do much with commands...

      I guess my general approach is to keep the command simple: 
mostly, it just calls a function.  The function can end with something like

   if a:endMode == "i"
     startinsert
   elseif a:endMode == "s"
     execute "normal! 0v$\<C-G>"
   elseif a:endMode == "v"
     normal! 0v$
   endif

(I was going to say that your command leaves me in Visual mode, not 
Select mode, until I remembered the 'selectmode' option.  Let's wait 
until someone complains, and then modify all our functions to respect 
this one!)

HTH					--Benji

Re: [Vim-latex-devel] Some problems with command implementation

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

On Sun, 29 Dec 2002, Srinath Avadhanula wrote:

> This works nicely! Thanks!
>
> I shall use this idea in packages.vim, templates.vim and
> custommacros.vim.
>

I see that there's still a problem:

The command:

com! Foo normal! i

doesn't leave the user in insert mode, whereas

com! Foo normal! 0v$<C-g>

does leave the user in select mode.

This seems to be a vim inconsistency... Any workarounds? Doing a
startinsert after the command is not going to cut it because sometimes
we want to end up in insert mode, sometimes in select mode.

Srinath

Re: [Vim-latex-devel] Some problems with command implementation

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

On Sun, 29 Dec 2002, Benji Fisher wrote:

>       How about this?  Note that I have changed the :if line in Foo() as
> well as the command.
>
> " ===
> fun! Foo(...)
>      if a:0 == 0 || a:1 == ""
>          let name = input('Whats your name?', 'bozo')
>      else
>          let name = a:1
>      endif
>      return 'Your name is '.name
> endfun
>
> inoremap <F3>       <C-r>=Foo()<CR>
> nnoremap <F3>       i<C-r>=Foo()<CR>
> inoremenu Help.foo      <C-r>=Foo()<CR>
> nnoremenu Help.foo      i<C-r>=Foo()<CR>
>
> com! -nargs=?  FooCom let s:FooVal = Foo(<q-args>) <Bar> normal! i<C-r>=s:FooVal<CR>
> " ===
Hello!

This works nicely! Thanks!

I shall use this idea in packages.vim, templates.vim and
custommacros.vim.

BTW, please check the latest version of latex-suite (from CVS) for bugs
etc. I want this to be the next stable release before we work on any
further enhancements.

Thanks,

Srinath

Re: [Vim-latex-devel] ``''<<>>

[Fabio S. <fab...@ti...>]

Srinath Avadhanula wrote:

>Hey Fabio,
>
>Benji implemented the new feature. I have uploaded the latest version
>which includes this.
>  
>
Cool guys, thank you all!

Hope this will be useful to others and not only to mine, of course !

Sorry for being so late in reply, I vas on vacation. Thanx again and a 
wonderful happy new year to you all!

Re: [Vim-latex-devel] Some problems with command implementation

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

Srinath Avadhanula wrote:
> Hello,
> 
> I am facing a problem implementing some commands in templates.vim,
> packages.vim and custommacros.vim... I have as an example, the following
> setup:
> 
> ---------------------%<---------------------
> fun! Foo(...)
>     if a:0 == 0
>         let name = input('Whats your name?', 'bozo')
>     else
>         let name = a:1
>     endif
>     return 'Your name is '.name
> endfun
> 
> inoremap <F3>       <C-r>=Foo()<CR>
> nnoremap <F3>       i<C-r>=Foo()<CR>
> inoremenu Help.foo      <C-r>=Foo()<CR>
> nnoremenu Help.foo      i<C-r>=Foo()<CR>
> 
> com! -nargs=?  FooCom normal! i<C-r>=Foo()<CR>
> ---------------------%<---------------------
> 
> With this setup, the insert and normal mode menu and mappings work as
> expected. It also works when FooCom is called with 1 argument, such as
>     :FooCom bar
> However, when FooCom is called without any arguments, we end up always
> getting a value 'bozo' for name because the <CR> gets eaten up by the
> input() immediately (I think). Whats a good way to make the command
> work? I tried placing a ":call getchar()" at the beginning of the
> function but even then the command without argument doesn't work...
> 
> Also, I cannot use something like:
> 
> com! -nargs=?  FooCom put!=Foo()
> 
> because in general Foo() will contain movement commands such as <Esc>3h
> and stuff... Moreover, sometimes, we would like to end up in say select
> mode after the function returns... So :put will not work...
> 
> Any ideas?
> 
> Srinath

      How about this?  Note that I have changed the :if line in Foo() as 
well as the command.

" ===
fun! Foo(...)
     if a:0 == 0 || a:1 == ""
         let name = input('Whats your name?', 'bozo')
     else
         let name = a:1
     endif
     return 'Your name is '.name
endfun

inoremap <F3>       <C-r>=Foo()<CR>
nnoremap <F3>       i<C-r>=Foo()<CR>
inoremenu Help.foo      <C-r>=Foo()<CR>
nnoremenu Help.foo      i<C-r>=Foo()<CR>

com! -nargs=?  FooCom let s:FooVal = Foo(<q-args>) <Bar> normal! 
i<C-r>=s:FooVal<CR>
" ===

For consistency, you could always call Foo() with one argument:  use "" 
instead of no arguments for the default behavior.

HTH					--Benji

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

[Carl M. <cm...@ma...>]

> I considered the <M-b> mapping for \mathbf{} as my greatest
> idea, 

Sorry, I meant that it WASN'T my greatest idea;  (irony intended).

Best wishes,
Carl

[Vim-latex-devel] Re: Some problems with command implementation

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

* On Fri, Dec 27, 2002 at 01:06:32AM -0800, Srinath Avadhanula <sr...@fa...> wrote:
> I am facing a problem implementing some commands in templates.vim,
> packages.vim and custommacros.vim... I have as an example, the
> following setup:
> 
> ---------------------%<---------------------
> inoremap <F3>       <C-r>=Foo()<CR>
> nnoremap <F3>       i<C-r>=Foo()<CR>
> com! -nargs=?  FooCom normal! i<C-r>=Foo()<CR>
> ---------------------%<---------------------
> 
> However, when FooCom is called without any arguments, we end up always
> getting a value 'bozo' for name because the <CR> gets eaten up by the
> input() immediately (I think). Whats a good way to make the command
> work? I tried placing a ":call getchar()" at the beginning of the
> function but even then the command without argument doesn't work...

I remember I add a similar problem sometimes ago. Unfortunately, I don't
remember how I solved it, or if I solved it.
I wonder if I didn't give up to finally call :normal from the
function...

And I guess that:
    command! -nargs=? FooCom :normal <F3>
does not solve your problem ?

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

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

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

Hello,

* On Fri, Dec 27, 2002 at 11:58:10AM -0800, Srinath Avadhanula <sr...@fa...> wrote:
> Your scheme seems quite excellent! I think the latter suggestion of
> making specific functions such as Tex_Convert_{from}_to_{to} and then
> calling these from a central Tex_Compile() function (the dependency
> engine) which uses options such as:
> 
> " Dependency definitions
> " for tex -> dvi -> ps -> pdf
> g:Tex_dvi_dependsOn = 'tex'
> g:Tex_ps_dependsOn = 'dvi'
> g:Tex_pdf_dependsOn = 'ps'
> " Compilation rules.
> g:Tex_CompileRule_dvi = 'latex \nonstopmode \input{$*}'
> g:Tex_CompileRule_ps = 'dvips -Ppdf $*'
> g:Tex_CompileRule_pdf = 'ps2pdf $*'

Hum ... If we adopt this approach (with a dependency engine), then the
compilation rules should be named regarding the source format as well.
Ie: we should have:
  g:Tex_CompileRule_ps2pdf  = 'ps2pdf $*'
and
  g:Tex_CompileRule_tex2pdf = 'pdflatex \nonstopmode \input{$*}'

BTW: the dependency engine should allow us to have an open system. For
instance, we could add a support for Tex4HT.

The last thing to "study" is how we will run/call this dependency
engine.

> is the best way to go... The Tex_Convert_tex_to_dvi and
> Tex_Convert_tex_to_pdf can both use another function Tex_Convert_tex
> with a few changed options... 

You're right. It will be neater (/more neat ?) than my current code.
I was first skeptical about the dependency engine. Now I think it should
not be so complex to implement.

> Maybe I will get around to it when I next get time... As of now, I am
> still fixing little bugs here and there... If you are interested, you
> could get access to our CVS treee...

May be the easiest thing to do is to start from the current code in
tex-tools.vim.
Moreover, it supports a little more advanced scheme regarding the way
the main latex file is specified (ie: it supports both your way and
Tomer's way ; and personnally, I prefer Tomer one's ;-)).
tex-tools.vim does also try to take care of many oddities like how to
detect that a :make failed, etc. But there are also unsolved (at least,
I am not satisfied by my workarounds) issues like :grep from win32-vim
launch from cygwin.

> On Thu, 26 Dec 2002, Luc Hermitte wrote:
> > 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)
> 
> Well, as of now latex-suite does this in 2 ways. 
> - [.. auctex's way ..]

I do know it. But I found this way hard to configure to one's
preferences.

> - It also supports "custom macros". These are basically files in the
> latex-suite/macros/ directory. Your feature could be implemented as:
> inoremap <C-x>t    <C-r>=Tex_ReadCustomMacro()<CR>
> 
> This pops up a prompt asking the user to choose from the files found
> in the macros/ directory and asks the user to choose one. This is then
> read in. The file can contain optional placeholders etc...

If I remember well, this second way uses an earlier (and official)
version of mu-template.
I have added many things since the last official release. Moreover, it
is not limited to LaTeX.

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

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

[Carl M. <cm...@ma...>]

On Fri, Dec 27, 2002 at 03:31:48AM +0100, Luc Hermitte wrote:
> BTW, I prefer ']bf' (or ']mbf') to '<M-b>'. In the long run I'm
> interrested in a single mapping that will insert '\textbf{}' or
> '\mathbf{}' according to the context.

I considered the <M-b> mapping for \mathbf{} as my greatest
idea, it was just that the Alt key is handy, and I don't use
it for anything else.  Possibly, there should be a second
"mapleader" key, in addition to "`" (backtick).  Maybe the
semicolon key ";" is worth considering, although it is used
in typing.  Perhaps ";" could begin all sorts of macros
which would adjust the font.  In that case, ";;" (two
semicolons) could be used to insert a single semicolon.
Or, maybe <C-g> is a good choice;  it's not used, and it's
easy to reach.  Also, <C-`> (control-backtick) is a
possibility.

Best wishes,
Carl

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

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

* On Thu, Dec 26, 2002 at 04:51:00PM -0800, Srinath Avadhanula <sr...@fa...> wrote:
> > Why? pdflatex thing works good enough. 

Not always. I used pst-uml for a C++ course I updated. As I had not
installed pdfTricks on my system (actually, I am not sure that miktex
supports pdfTricks), I wasn't able to use pdflatex. I had to use dvips +
ps2pdf. While I used pdflatex for the subjects of the exams.

> [...]
> if !hasmapto('Tex_MathBF', 'i') && mapcheck('<M-b>', 'i') == ''
> 	inoremap <buffer> <silent> <M-b> <C-r>=Tex_MathBF()<CR>
> endif

I see another problem here. Meta mappings are a pure headache!
As often as possible, I suggest that latex-suite does not propose them
by default. For instance, here <M-b> is linked to 'â' with my
configuration. That means, I will have to hit '<c-v>^age' if I want to
write 'âge' and not '\mathbf{ne}<++>'.

BTW, I prefer ']bf' (or ']mbf') to '<M-b>'. In the long run I'm
interrested in a single mapping that will insert '\textbf{}' or
'\mathbf{}' according to the context.

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

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

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

Well, at least one issue seems to be decided upon. The diacritics will
go!

Your scheme seems quite excellent! I think the latter suggestion of
making specific functions such as Tex_Convert_{from}_to_{to} and then
calling these from a central Tex_Compile() function (the dependency
engine) which uses options such as:

" Dependency definitions
" for tex -> dvi -> ps -> pdf
g:Tex_dvi_dependsOn = 'tex'
g:Tex_ps_dependsOn = 'dvi'
g:Tex_pdf_dependsOn = 'ps'
" Compilation rules.
g:Tex_CompileRule_dvi = 'latex \nonstopmode \input{$*}'
g:Tex_CompileRule_ps = 'dvips -Ppdf $*'
g:Tex_CompileRule_pdf = 'ps2pdf $*'

is the best way to go... The Tex_Convert_tex_to_dvi and
Tex_Convert_tex_to_pdf can both use another function Tex_Convert_tex
with a few changed options... The Tex_Convert_tex can be a special
function which also runs the makeindex, bibtex etc as needed.

Maybe I will get around to it when I next get time... As of now, I am
still fixing little bugs here and there... If you are interested, you
could get access to our CVS treee...

On Thu, 26 Dec 2002, Luc Hermitte wrote:

> 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)
>

Well, as of now latex-suite does this in 2 ways. If the user presses the
<F5> key on an empty line, then it prompts him to insert an environment
from amongst a list. (This idea is from auctex.vim) It also supports
"custom macros". These are basically files in the latex-suite/macros/
directory. Your feature could be implemented as:

inoremap <C-x>t    <C-r>=Tex_ReadCustomMacro()<CR>

This pops up a prompt asking the user to choose from the files found in
the macros/ directory and asks the user to choose one. This is then read
in. The file can contain optional placeholders etc...

Srinath

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

[Carl M. <cm...@ma...>]

On Thu, Dec 26, 2002 at 04:51:00PM -0800, Srinath Avadhanula wrote:
> 
> Also, Carl Mueller has made invaluable contributions to latex-suite. If
> he desires, he could join the team too
> 

I'm not sure that I have time to participate in the way that
everyone else on this list does.  Also, I have already
contributed most of my ideas.  If I come up with anything
else, I could send it to Srinath, and I'll still participate
in the mailing list (if I think of anything else).

Best wishes,
Carl

[Vim-latex-devel] Some problems with command implementation

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

Hello,

I am facing a problem implementing some commands in templates.vim,
packages.vim and custommacros.vim... I have as an example, the following
setup:

---------------------%<---------------------
fun! Foo(...)
    if a:0 == 0
        let name = input('Whats your name?', 'bozo')
    else
        let name = a:1
    endif
    return 'Your name is '.name
endfun

inoremap <F3>       <C-r>=Foo()<CR>
nnoremap <F3>       i<C-r>=Foo()<CR>
inoremenu Help.foo      <C-r>=Foo()<CR>
nnoremenu Help.foo      i<C-r>=Foo()<CR>

com! -nargs=?  FooCom normal! i<C-r>=Foo()<CR>
---------------------%<---------------------

With this setup, the insert and normal mode menu and mappings work as
expected. It also works when FooCom is called with 1 argument, such as
    :FooCom bar
However, when FooCom is called without any arguments, we end up always
getting a value 'bozo' for name because the <CR> gets eaten up by the
input() immediately (I think). Whats a good way to make the command
work? I tried placing a ":call getchar()" at the beginning of the
function but even then the command without argument doesn't work...

Also, I cannot use something like:

com! -nargs=?  FooCom put!=Foo()

because in general Foo() will contain movement commands such as <Esc>3h
and stuff... Moreover, sometimes, we would like to end up in say select
mode after the function returns... So :put will not work...

Any ideas?

Srinath