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

Re: [Vim-latex-devel] (La)TeX compilation

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

Hi Luc,

> > if g:Tex_MainFileExpr != ''
> >     exec 'let retval = '.g:Tex_MainFileExpr
> >     return retval
> > endif
>
> If these 4 lines of code are present within Tex_GetMainFileName(), it
> sounds perfect.
I wonder if I already told you about this, but I implemented the
Tex_MainFileExpression we discussed before. I have updated the relevant
documentation. Take a look at:

http://vim-latex.sourceforge.net/documentation/latex-suite/latex-master-file.html

It tells how to use Tex_MainFileExpression.

> I was thinking of a function that centralizes all this
> mainfile-determination heuristic.
> => the functions depending on the project's main-file are easy to
> write/maintain.
>
This is an excellent idea. Initially I was thinking that
Tex_GetMainFileName() will always return a filename unlike the present
way in which it returns a non-empty string only if a .latexmain file is
present. In the future, it will just return expand('%') if a .latexmain
is not found...

However, there is no good way to make Tex_GetMainFileName also contain
logic of whether a 'makefile' exists etc.

Srinath

Re: [Vim-latex-devel] bug in compiler/tex.vim

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

On Wed, 23 Jul 2003, PAN Shizhu wrote:

> You defined a character which looks like a reversed `!' as the delimeter of
> global var g:Tex_IgnoredWarnings, but this character will definetely cause
> problem on many systems (mainly non-latin systems such as Chinese, Japanese
> and Korean).

Okay the problem with the inverted '!' character causing i8n problems is
fixed in the latest dated release. Get it from the latex-suite download
page.

Srinath

Re: [Vim-latex-devel] bug in compiler/tex.vim

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

Hey Pan,

On Wed, 23 Jul 2003, PAN Shizhu wrote:

> You defined a character which looks like a reversed `!' as the delimeter of
> global var g:Tex_IgnoredWarnings, but this character will definetely cause
> problem on many systems (mainly non-latin systems such as Chinese, Japanese
> and Korean).
>
We have actually received this complaint before but unfortunately,
fixing it always got put on the backburner. I will however, fix this
today and post a new version on the web-page. I think we can use "\n" to
delimit the items...

Hopefully, the release at the end of the week will not have any such
problems again. All characters should have ascii value < 128.

Srinath

[Vim-latex-devel] bug in compiler/tex.vim

[PAN S. <Shi...@ne...>]

I did downloaded each version of vim-latex suite, but I cannot sucessfully 
installing it in Vim 6.2 without problem. There will be lots of run-time 
errors reported when loading scripts in latex-suite.

--

Finally I realized that there must be something wrong and have to dive into 
the .vim source code myself.

The problem is found at compiler/tex.vim, Line 78-81, Tex_IgnoredWarnings

You defined a character which looks like a reversed `!' as the delimeter of 
global var g:Tex_IgnoredWarnings, but this character will definetely cause 
problem on many systems (mainly non-latin systems such as Chinese, Japanese 
and Korean).

On my system, any ASCII character with value larger than 0x9f will be treated 
as an indication of `double character', and any ASCII character between 0x80 
and 0x9f will be ignored if it is not following a character >0x9f. In another 
word, characters with highest bit `1' will be treated specially and should be 
reserved only for special use.

Since you used a `reversed !' as delimeter of global var, which has an ASCII 
value of 0xa1 (10100001), this will be treated as an indication of `double 
character' on my system, and the next character, a single quotation mark, will 
be combined with the 0xa1, which forms 0xa127, then the VIM cannot identify 
the end of the string, thus vim will always complain error compling the 
compiler/tex.vim

--

Possible solutions for this are: 
1. avoid using special character, change to another character, which belongs 
to standard 7-bit ASCII range, i.e. between 0x20 and 0x7f

2. or if you do want to keep 0xa1 as the delimeter, append a chacter so that 
it won't eat up the single quotationi mark after that, and letting vim 
compiling this file sucessfully (not sure if it runs okay, but should compile 
ok, and uses can change this in `texrc').

3. texrc should be altered as well...

--

Thanks.
Pan Shizhu

Re: [Vim-latex-devel] A question about placing files

[Mikolaj M. <mi...@wp...>]

On Sun, Jul 20, 2003 at 06:28:11PM -0700, Srinath Avadhanula wrote:
> A few months ago, when we began extending latex-suite with Carl
> Mueller's addons, (brackets.vim etc) we decided that a good place for
> them to go was in ~/.vim/ftplugin/tex/. But now I am having second
> thoughts... For one, making new addons reside in the tex/ directory
> means that if for instance the user wants to uninstall latex-suite, then
> he will have to remove each individual file from there. If all files of
> latex-suite resided in latex-suite/ except for a few necessary ones in
> other places, uninstalling is much easier.

And uninstalling is the main reason to made this change.

> The files which we already distribute in the tex/ directory will most
> probably need to stay there for the sake of compatibility, but should we
> be creating a new directory addons/ in latex-suite and putting new stuff
> there and then let main.vim do something like
>     :runtime! ftplugin/latex-suite/addons/*.vim

I think we can move this files. The worst thing will be wave of mails:
This doesn't work, but advantages are more important (IMO of course).

> There is(are) some disadvantages:
> 1. Vim sources files in the tex/ directory for every Filetype tex event.
>    We will have to write code to do this for files in the addons/
>    directory.

Yes, this is problem :/

BTW I have got from Bram positive answer for my request: .bbl files will
be recognized as tex filetype. 

m.

Re: [Vim-latex-devel] New stable release

[Mikolaj M. <mi...@wp...>]

On Thu, Jul 17, 2003 at 07:27:27PM -0700, Srinath Avadhanula wrote:
> Please check the comments in the latest cvs log of the makefile to see
> how to do all the web-page maintainence and temporary releases remotely.
> We should avoid directly editing the web-page, except for the rare
> instance when we are making a major release.

OK.

> > To make links work properly from site you have to change value of $date
> > variable in download.inc . Last time I wasn't able to force CVS htdocs
> > to work thus I make changes directly in web page :/ Of course I can do
> > it myself, just write when.
> >
> You should not have to change download.inc. I have changed download.inc
> about a month back so that it includes timestamp.inc which in turn
> automatically gets updated when we do "make release" from vimfiles/.
> What should we call the next version? :) 2.0? I wish we could have
> release something like 3.1.41... Oh well...

I think the current releases is still 1.x
IMO we should change major number when breaking compability with older
versions of Vim.

Of course we can change current naming system instantly. 1.8 looks good
;)

m.

[Vim-latex-devel] A question about placing files

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

Hello

I wanted to get a few opinions on whether the current directory tree of
latex-suite is optimal for the long run. As of now, latex-suite has
files in the following hierarchy:

~/.vim
    - plugin/
        - imaps.vim
        - syntaxFolds.vim
        - etc.
    - ftplugin/
        - tex_latexSuite.vim
        - tex/
            - texviewer.vim
            - brackets.vim
        - latex-suite/
            - main.vim
            - compiler.vim
            - etc.

A few months ago, when we began extending latex-suite with Carl
Mueller's addons, (brackets.vim etc) we decided that a good place for
them to go was in ~/.vim/ftplugin/tex/. But now I am having second
thoughts... For one, making new addons reside in the tex/ directory
means that if for instance the user wants to uninstall latex-suite, then
he will have to remove each individual file from there. If all files of
latex-suite resided in latex-suite/ except for a few necessary ones in
other places, uninstalling is much easier.

The files which we already distribute in the tex/ directory will most
probably need to stay there for the sake of compatibility, but should we
be creating a new directory addons/ in latex-suite and putting new stuff
there and then let main.vim do something like

    :runtime! ftplugin/latex-suite/addons/*.vim

There is(are) some disadvantages:
1. Vim sources files in the tex/ directory for every Filetype tex event.
   We will have to write code to do this for files in the addons/
   directory.

Let me know what your views are.

Thanks,
Srinath

[Vim-latex-devel] How to make releases/update the web-page etc.

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

Hey Mikolaj (and everyone else who might be interested),

Please use the method described below for updating the web-page etc. The
latest makefile in the vimfiles/doc module has three additional targets:

release:
    For making temporary dated releases of the form
    latexSuite20030618.zip etc. This target runs the executable
    /home/groups/v/vi/vim-latex/bin/upload, which does the following:

    1. updates a checked out copy of latex-suite kept in
       vim-latex/testing/vimfiles to the latest cvs revision.
    2. creates archives of the form latexSuite20030617.[zip/tar.gz]
    3. ... and moves them to the download area of the vim-latex htdocs/
       directory.
    4. It then updates htdocs/timestamp.inc with the date at which the
       archives were created so that the download section points to the
       latest dated release.

updoc:
    For updating the documentation to the latest cvs. This target
    updates a copy of the ~/vimfiles/doc module kept in
    /home/groups/v/vi/vim-latex/htdocs/documentation/ to the latest cvs
    and then creates latex-suite.html and the chunked html files in
    documentation/latex-suite/*.html

uphtdocs: for updating the htdocs directory (the web-page) with the
    latest cvs. Will also update the package and template list. Will
    also update the ChangeLog which is linked from the download page.

I have tried to setup the webpage in such a way that the entire
maintainence can be done via make remotely. Please do it this way. For
example, when making changes to the web-page, make changes in a locally
checked out copy and do "make uphtdocs". If you make some changes to the
user manual, do "make updoc". If you wish to make a dated release to fix
a temporary bug-fix etc, do "make release".

Also note that whenever you make a change to latex-suite.xml, you need
to also change latex-suite.txt simultaneously using db2vim and then
commit them both at the same time. I wrote an email earlier about how to
use db2vim. Hope it is working for you...

I have also changed the permissions for all files in the htdocs/
directory to ug+w. which means we should both be able to write to it.
However, I saw that some of the files are only writable by you. Please
do
$ chmod -R ug+w *
in the htdocs/ directory.

Srinath

Re: [Vim-latex-devel] New stable release

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

Hey Mikolaj,

On Thu, 17 Jul 2003, Mikolaj Machowski wrote:

> I think it is time for new stable release.
> 1. Many bugfixes over the last one.
> 2. I was asked to prepare package for TeXLive8. It would be good if
> this package was the same as "official" Latex-suite package (eg. as
> a reference point for users).

I agree. We have been putting off the next release for sometime now...
Another good reason for making an official release is that we can have
a branch which is dedicated solely to bug-fixing.

> I'd like to send this package to the end of the week.
> But I am not sure if I can properly make docs.
> Srinath - could you prepare package?
> I have updated ChangeLog looking through my mail archive. Could you
> check if everything was included?
>
Please check the comments in the latest cvs log of the makefile to see
how to do all the web-page maintainence and temporary releases remotely.
We should avoid directly editing the web-page, except for the rare
instance when we are making a major release.

For now, I have updated the documentation on the web-page and created
the next "dated" release.

> To make links work properly from site you have to change value of $date
> variable in download.inc . Last time I wasn't able to force CVS htdocs
> to work thus I make changes directly in web page :/ Of course I can do
> it myself, just write when.
>
You should not have to change download.inc. I have changed download.inc
about a month back so that it includes timestamp.inc which in turn
automatically gets updated when we do "make release" from vimfiles/.

What should we call the next version? :) 2.0? I wish we could have
release something like 3.1.41... Oh well...

Srinath

[Vim-latex-devel] New stable release

[Mikolaj M. <mi...@wp...>]

Hello,

I think it is time for new stable release.
1. Many bugfixes over the last one.
2. I was asked to prepare package for TeXLive8. It would be good if
this package was the same as "official" Latex-suite package (eg. as
a reference point for users). 

I'd like to send this package to the end of the week.
But I am not sure if I can properly make docs.
Srinath - could you prepare package?
I have updated ChangeLog looking through my mail archive. Could you
check if everything was included?

To make links work properly from site you have to change value of $date
variable in download.inc . Last time I wasn't able to force CVS htdocs
to work thus I make changes directly in web page :/ Of course I can do
it myself, just write when.

m.

Re: [Vim-latex-devel] Completion of Tcommands

[Mikolaj M. <mi...@wp...>]

On Tue, Jul 15, 2003 at 01:20:28AM +0200, Luc Hermitte wrote:
> * On Mon, Jul 14, 2003 at 02:57:01PM -0700, Srinath Avadhanula <sr...@fa...> wrote:
> > BTW, I just found out that the -complete=custom,Foo works only for vim
> > 6.2+. Do we still want to implement this? We will be generating errors
> > for the majority of users now...
> Nice to know!
> > On vim 6.1, I get an error if I do
> > 
> > :com -nargs=1 -complete=custom,Foo Bar
> > 
> > E180: Invalid complete value: custom,Foo Bar
> IMHO, It is not really an issue. Something like this will do the trick.
>     if version < 602
>      :com -nargs=1 Bar
>     else
>      :com -nargs=1 -complete=custom,Foo Bar
>     endif

I just committed it to the CVS :)

m.

Re: [Vim-latex-devel] Completion of Tcommands

[Mikolaj M. <mi...@wp...>]

On Mon, Jul 14, 2003 at 02:57:01PM -0700, Srinath Avadhanula wrote:
> On Mon, 14 Jul 2003, Mikolaj Machowski wrote:
> > Really doc entries are necessary? I implemented it because completion
> > was the natural thing.
> BTW, I just found out that the -complete=custom,Foo works only for vim
> 6.2+. Do we still want to implement this? We will be generating errors
> for the majority of users now...
> On vim 6.1, I get an error if I do
> :com -nargs=1 -complete=custom,Foo Bar
> E180: Invalid complete value: custom,Foo Bar

Ah, yes I checked docs for 6.1 and there is no mention about
-complete=custom. But I think this is nice feature and we can have it
both ways. Just add checking for v:version.

if v:version >= 602
	command! ... -complete,custom
else
	command! ...
endif

BTW I think with 6.3 we should think with breaking backward compability.
There will be nice features:
- :popup menu (it is already)
- "DualHead" editing

But we had plenty of time :)

m.

[Vim-latex-devel] (La)TeX compilation

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

Hello Srinath.

* On Mon, Jul 14, 2003 at 06:46:01PM -0700, Srinath Avadhanula <sr...@fa...> wrote:
> On Tue, 15 Jul 2003, Luc Hermitte wrote:
> > Otherwise, I would have a request (partly implemented in my
> > ftplugin).  I'd like to have the choice of the way used to define
> > the main TeX document between:
> > - using a [bg]:dedicated_variable_for_this (whatever the final name
> >   is)
> > - or using mainfile.{theproject} (or another name i don't remember)
> >   as you originally planned
> > - or using a Makefile (if the right conditions are fulfilled)
> > - or using the name of the current buffer.
> >
> >
> For a while now, I have been thinking of a way to let the user be able
> to very easily specify the main file name in whatever way he
> chooses...
> Right now, a central function Tex_GetMainFileName() is called whenever
> a function needs the main tex file name (there are quite a few
> functions which need this info). Right now, Tex_GetMainFileName()
> checks for a {fname}.latexmain file and returns {fname} if possible,
> otherwise it just returns '' (the calling function is supposed to
> handle the case when it returns ''). There are various ways in which
> we could make this customizable.
> 
> Let the user define a variable g:Tex_MainFileExpr ('' by default)
> which latex-suite will use as:
> 
> if g:Tex_MainFileExpr != ''
>     exec 'let retval = '.g:Tex_MainFileExpr
>     return retval
> endif

If these 4 lines of code are present within Tex_GetMainFileName(), it
sounds perfect.

> You could then define g:Tex_MainFileExpr to be whatever you like. For
> instance, you could use your extended let-modeline function here (if I
> remember the nomenclature correctly).

Well ... This is the nomenclature I used, but I am not sure it is
English-proof.

> How does this sound? Is it sufficient? Or were you thinking of
> something else entirely?

I was thinking of a function that centralizes all this
mainfile-determination heuristic. 
=> the functions depending on the project's main-file are easy to
write/maintain.

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

[Vim-latex-devel] (La)TeX compilation

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

* On Tue, Jul 15, 2003 at 12:13:51AM -0700, Srinath Avadhanula <sr...@fa...> wrote:
> On Tue, 15 Jul 2003, Luc Hermitte wrote:
> > - Why
> >     exec 'silent! 0r! '.g:Tex_CatCmd.' '.a:filename
> >   and not just:
> >     if fileexists(a:filename)
> >       exec 'silent! 0r '.a:filename
> >     endif
> >   ?
> 
> I tried doing :r {fname} before but found that it actually creates a
> new buffer in the process. I think that creating unused buffers is a
> greater evil than spawning a shell command. If you notice, I take a
> lot of care to only create one temporary buffer in a session. 

What the hell ?!
I wonder why ":r" and ":r! cat" differ so much. And what is the need of
keeping an unused buffer ...
Anyway. Thanks for the info!

> Also r!  {fname} seems to spawn the shell in the background in gvim,
> so its not too intrusive... 

But, problem: what are the correct external-program amiga, macos, ... ?

> I submitted a feature request about a function filecontents() in vim
> which would basically return a <NL> seperated string of the contents
> of a file, but I have a feeling its going to be neglected like always.
> Sometimes I really wish viml had a few more basic building blocks.

So do I.

> > - Why
> >     if search(a:regexp, 'w')
> >       let retVal = 1
> >     else
> >       let retVal = 0
> >     endif
> >   instead of:
> >       let reVal = search(a:regexp, 'w') > 0
> >   ?

> Heh :) I guess it does make things more compact. I would go so far as to
> say that I should have simply done:
> 
> let retVal = search(..., ...)

Yes and no. "search(...)" is not "boolean-like" as it is an int.
"search(...)>0" is ; as it values 0 or 1.

> [...]
> So whats correct? Depending on return values from boolean algebra might
> lead to inconsistencies, so be warned.

I am. :)

> BTW, Luc: how did you get the logic for what steps to follow to
> generate the DVI file correctly? 

Mainly from Tomer Kol's initial program. So I will not be surprised to
learn that it differs from the ones we can find in others
Makefile/scripts.

> I notice that TKMakeDVI first runs bibtex if file.aux contains
> \bibdata even before running latex. 
> But this seems to be incorrect in situations where the modification is
> to remove a bibliographic entry... i.e, if initially the file
> contained
> 
> \bibliography{fname}
> 
> and I removed this line or changed fname and then did TKMakeDVI, then it
> would wrongly make bibtex scan fname... I hope you see the problem.

Yes indeed.
However, bibtex is also run after latex. And if the .bbl file has
changed then we know that latex must be re-run.
May be to much compilations and bibtex executions are made. But the
result will be correct.

I don't remember why I/we considered the execution of bibtex after latex
wasn't enough. Probably that sometimes bibtex need to be run twice. But
I don't remember when -- I haven't use LaTeX for a while.

So far, it seems that the following may be enough:

0.0- need_to_rerun = 1
x.0- while need_to_rerun
x.1- latex
1.2- if !grep(\bibdata, mainfile.'.tex') => 1.3
     if fileexists(mainfile.'.bbl') => backup
     bibtex
     if .bbl and .bll.bak differs => need_to_rerun = 1
x.3- if grep(Rerun, mainfile.'.log')
x.0- while need_to_rerun
x.1- latex
y.2- nothing
...


BTW: there is a thing i think is a strench of tex-tools: bibtex,
makeindex, dvips, ... are used as 'makeprogram's => the errors can be
seen in a :cwindow.
This requires that compiler/tex.vim defines a function/command that
reset &efm to (pdf)(La)TeX settings -- without having to resource this
file.

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

Re: [Vim-latex-devel] Completion of Tcommands

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

A bit more discussion...

On Tue, 15 Jul 2003, Luc Hermitte wrote:
> - Why
>     exec 'silent! 0r! '.g:Tex_CatCmd.' '.a:filename
>   and not just:
>     if fileexists(a:filename)
>       exec 'silent! 0r '.a:filename
>     endif
>   ?
>   It would reduce the problems we can experience because of external
>   programs -- another source of headaches.

I tried doing :r {fname} before but found that it actually creates a new
buffer in the process. I think that creating unused buffers is a greater
evil than spawning a shell command. If you notice, I take a lot of care
to only create one temporary buffer in a session. Also r! {fname} seems
to spawn the shell in the background in gvim, so its not too
intrusive... I submitted a feature request about a function
filecontents() in vim which would basically return a <NL> seperated
string of the contents of a file, but I have a feeling its going to be
neglected like always. Sometimes I really wish viml had a few more basic
building blocks.

> - Why
>     if search(a:regexp, 'w')
>       let retVal = 1
>     else
>       let retVal = 0
>     endif
>   instead of:
>       let reVal = search(a:regexp, 'w') > 0
>   ?
>   I'm a militant for the direct use of boolean expressions whenever we
>   have "if expression then a=true else a=false endif" :)
>
Heh :) I guess it does make things more compact. I would go so far as to
say that I should have simply done:

let retVal = search(..., ...)

I have only rarely used booleans in places other than if statements
etc... But I guess logical expressions are not really consistent across
languages. For example, in vim:

echo 2 && 3

prints 1

whereas in python (which is becoming my favorite language),

print 2 and 3

will print 3 (which seems more logical actually as far as expression
short-circuiting goes... for example, you could do

something = istrue and file.readlines()

will make something contain the contents of the file if istrue is true,
a sort of if then statement.
)

So whats correct? Depending on return values from boolean algebra might
lead to inconsistencies, so be warned.

BTW, Luc: how did you get the logic for what steps to follow to generate
the DVI file correctly? I notice that TKMakeDVI first runs bibtex if
file.aux contains \bibdata even before running latex. But this seems to
be incorrect in situations where the modification is to remove
a bibliographic entry... i.e, if initially the file contained

\bibliography{fname}

and I removed this line or changed fname and then did TKMakeDVI, then it
would wrongly make bibtex scan fname... I hope you see the problem.

Thanks,
Srinath

Re: [Vim-latex-devel] Completion of Tcommands

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

Hi Luc,

I will reply to the other points later (several very helpful hints
there...), but I couldn't resist replying to the very last point now...

On Tue, 15 Jul 2003, Luc Hermitte wrote:
> Otherwise, I would have a request (partly implemented in my ftplugin).
> I'd like to have the choice of the way used to define the main TeX
> document between:
> - using a [bg]:dedicated_variable_for_this (whatever the final name is)
> - or using mainfile.{theproject} (or another name i don't remember) as
>   you originally planned
> - or using a Makefile (if the right conditions are fulfilled)
> - or using the name of the current buffer.
>
>
For a while now, I have been thinking of a way to let the user be able
to very easily specify the main file name in whatever way he chooses...
Right now, a central function Tex_GetMainFileName() is called whenever
a function needs the main tex file name (there are quite a few functions
which need this info). Right now, Tex_GetMainFileName() checks for
a {fname}.latexmain file and returns {fname} if possible, otherwise it
just returns '' (the calling function is supposed to handle the case
when it returns ''). There are various ways in which we could make this
customizable.

Let the user define a variable g:Tex_MainFileExpr ('' by default)
which latex-suite will use as:

if g:Tex_MainFileExpr != ''
    exec 'let retval = '.g:Tex_MainFileExpr
    return retval
endif

You could then define g:Tex_MainFileExpr to be whatever you like. For
instance, you could use your extended let-modeline function here (if
I remember the nomenclature correctly).

How does this sound? Is it sufficient? Or were you thinking of something
else entirely?

Srinath

Re: [Vim-latex-devel] Completion of Tcommands

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

* On Mon, Jul 14, 2003 at 02:57:01PM -0700, Srinath Avadhanula <sr...@fa...> wrote:
> BTW, I just found out that the -complete=custom,Foo works only for vim
> 6.2+. Do we still want to implement this? We will be generating errors
> for the majority of users now...

Nice to know!

> On vim 6.1, I get an error if I do
> 
> :com -nargs=1 -complete=custom,Foo Bar
> 
> E180: Invalid complete value: custom,Foo Bar

IMHO, It is not really an issue. Something like this will do the trick.
    if version < 602
     :com -nargs=1 Bar
    else
     :com -nargs=1 -complete=custom,Foo Bar
    endif

And i'm sure it is easy to write a wrapper function/command to ease the
definition of such commands.

As a consequence, the auto-completion would be a feature of vim 6.2+
only...

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

Re: [Vim-latex-devel] Completion of Tcommands

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

Hello,

* On Sun, Jul 13, 2003 at 11:36:28PM -0700, Srinath Avadhanula <sr...@fa...> wrote:
> > My idea is that TTemplate, TMacros, ... would invoke the same
> > function but with different built-in parameters.
> >
> As of now, the templates, custom macros and IMAP() functions in
> latex-suite are all handled by a central
> IMAP_PutTextWithMovement() function with differing arguments and
> wrapper functions (for example, TTemplate provides a prompt for the
> template files etc). So we do not really repeat any work. The jump
> function and marker functionality is all in plugin/imaps.vim.

OK.
But the expansion of "!com!...!com!" and "!exe!...!exe!", ...
are unique to templates, if I am correct. Feature which would be very
interresting to have with macros/packages/...

<adv.>

> Also, one sufficiently important implementation issue in the IMAP()
> function is that you do not have to bind all expansions to non-keyword
> characters like <C-r><space> or <C-r><tab> etc. Most expansions in
> latex-suite are for example triggered just as :imaps work except for
> being able to correct, no timeout etc. Basically, only the last
> character of the first argument of an IMAP() is actually :map'ped to a
> LookupCharacter() function. A reverse lookup over previously typed
> characters is made whenever such a character is encountered and if
> there is a possible completion, it is used... This enables you to have
> 2-key mappings like `8 -> \infty which would have been pretty annoying
> to use if we had to type 8<C-r><tab> each time...

That is not really an issue, µTemplate is easy to enhance with
something like (syntax not tested):
    function s:BindTemplate(file)
        let the_map = fnamemodify(a:file, ":e")
        call IMAP_smart_bind(s:the_leader.the_map, 
             \ "\<c-o>:MuTemplate tex/".the_map)
        " IMAP_smart_bind() beeing the core of the IMAP_... functions.
    endfunction
    command! BindTemplate :call s:BindTemplate("<args>")
    SearchInRuntime! :BindTemplate template/tex/template.*

As a result, if you type "`figure", it will get expanded with the right
template-file -- it is also possible to automatically build more
complex/specific keybindings than this simplistic one.

But, it is already (at this time) possible to use it a stubs-expander
that expands on back-quotes (like Dr Chip Campbell's stubs-expander) --
by just mapping the expansion to "`" instead of "<c-r><tab>", ...
    => :imap <buffer> ` <Plug>MuT_cword
(if you'd rather use <F5> ... it is easy to adapt ... ; for personal
reasons, I've chosen <c-r><tab>)

Which is IMHO more interresting than "`figure" because "f`", "fi`",
..."figure`"  also work -- and if several choices are available ... they
will be proposed to the end-user.

[Little remark: the back-quote is not a French-friendly character as it
is hard-binded to <altgr-7>. French keyboards are definitively
CS-unfriendly :(
]

</adv.>

But that was not my initial point.
My main point is: wouldn't it be more interresting to 
- concentrate on building a really powerfull templates-expander,
- and wrap its calls into functions/commands/menus for
  macros/templates/packages.

BTW, i fixed some little problems from the original µTemplate plugin ;
even one (and a half) i personnaly introduced (two :<range>substitute
calls for "compute" and "execute" was a awkward! ; several "execute"
commands have no reasons to be on a same line.)

<adv.>
Last parenthesis.  The only things you may consider as a lack in my
current version on µTemplate:
- a little patch is still to be applied regarding non-latin1 issues
- placeholders are not converted by the plugin, but instead inserted
  through a call to a dedicated function.
- the filenames of the templates are quite heavy
  ({rtp}/template/template.{the_real_name})
</adv.>

______________

> BTW, very recently I started to have to compile some files multiple
> times and therefore quickly felt the need for a function like
> TKMakeDVI in tex-tools.vim (part of your latex ftplugin package). I
> looked at it and have been extracting parts of it to use in
> latex-suite. 

Feel free to do so !

> I wish to borrow the basic logic of the multiple compilations, but I
> wish to implement various things like TKFilesDiffer() differently to
> make it cross-platform without a lot of platform detection logic... 

This function was definitivelly an headache ! I made minor modifications
on Tomer Kol's initial function, but still it is not perfect :-(

> I have a very rough (and incomplete) draft of this on a non-MAIN
> branch in the vim-latex cvs tree. 


> Another implementation issue is that I have a parallel python
> implementation of the same thing and the script should automatically
> detect python and use the python function instead so all the things
> like filediff's etc can be handled via python much more cleanly than
> in viml.

Sounds like a good idea!

> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/vim-latex/vimfiles/ftplugin/tex/Attic/latexm.vim?rev=1.1.2.3&only_with_tag=latex-multi-compile&content-type=text/vnd.viewcvs-markup

After a quick check:
- [adv.] I have dedicated a plugin to portability issues. For instance
  it defines a function SysCat() that returns the name of the external
  program to use according to the current system -- and the path to the
  parameter-files is correctly converted!
  -> system_utils.vim
- Why 
    exec 'silent! 0r! '.g:Tex_CatCmd.' '.a:filename
  and not just:
    if fileexists(a:filename)
      exec 'silent! 0r '.a:filename
    endif
  ?
  It would reduce the problems we can experience because of external
  programs -- another source of headaches.
- Why 
    if search(a:regexp, 'w')
      let retVal = 1
    else
      let retVal = 0
    endif
  instead of:
      let reVal = search(a:regexp, 'w') > 0
  ?
  I'm a militant for the direct use of boolean expressions whenever we
  have "if expression then a=true else a=false endif" :)

_________

Otherwise, I would have a request (partly implemented in my ftplugin).
I'd like to have the choice of the way used to define the main TeX
document between:
- using a [bg]:dedicated_variable_for_this (whatever the final name is)
- or using mainfile.{theproject} (or another name i don't remember) as
  you originally planned
- or using a Makefile (if the right conditions are fulfilled)
- or using the name of the current buffer. 
  

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

Re: [Vim-latex-devel] Completion of Tcommands

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

On Mon, 14 Jul 2003, Mikolaj Machowski wrote:

> Really doc entries are necessary? I implemented it because completion
> was the natural thing.

BTW, I just found out that the -complete=custom,Foo works only for vim
6.2+. Do we still want to implement this? We will be generating errors
for the majority of users now...

On vim 6.1, I get an error if I do

:com -nargs=1 -complete=custom,Foo Bar

E180: Invalid complete value: custom,Foo Bar

Srinath

Re: [Vim-latex-devel] Completion of Tcommands

[Mikolaj M. <mi...@wp...>]

On Sun, Jul 13, 2003 at 11:50:50PM -0700, Srinath Avadhanula wrote:
> On Sat, 12 Jul 2003, Mikolaj Machowski wrote:
> > Candidates are:
> > I'd like to add completion of commands similar to those implemented
> > yesterday in TPackage. I would improve usability of Tcommands.
> >
> The completion for :TPackage was a good idea. Please update the
> documentation for the same... Dont worry about the typos :) I will
> correct the grammar etc. But its important it gets into the manual in
> some manner.

Really doc entries are necessary? I implemented it because completion
was the natural thing.

Before making it for TTemplate and TMacro- I think Luc has valid point.
Many functions there are redundant, also commands behave inconsistently
with commands elsewhere (eg. introduce PromptFor... commands for fast
choosing of macros). 
Proposition:
- merge custommacros.vim and templates.vim in one file: macros.vim
- move stuff for menus into texmenuconf.vim
- add PromptFor system
- unify functions.

> BTW, we need to sometime finalize the whole part-viewing thing. Its
> pretty half-baked right now. Also the project thing. Since I ripped out
> the old code from texviewer.vim, project files are absolutely unused. We
> should either remove the rest of the code supporting projects or find
> some other use for it. There is even a non-function menu item under the
> main latex-suite menu called Project which basically does nothing right
> now.

OK. What project should do:
1. Show in explorer window only project files
2. Could shorten scanning files - scan only files in project
   (lS cannot "think" about all combinations of placement of files, in
   more complex situations project will help).
3. Load, unload all files in project, eg. for :bufdo commands
4. Some help in compilation?

m.

Re: [Vim-latex-devel] Completion of Tcommands

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

On Sat, 12 Jul 2003, Mikolaj Machowski wrote:

> Candidates are:
> I'd like to add completion of commands similar to those implemented
> yesterday in TPackage. I would improve usability of Tcommands.
>
The completion for :TPackage was a good idea. Please update the
documentation for the same... Dont worry about the typos :) I will
correct the grammar etc. But its important it gets into the manual in
some manner.

I would think that having custom completion functions for the ones below
is also a good idea. But once again, please first write the
documentation if possible... I am pretty sure just a single line will
do...

BTW, we need to sometime finalize the whole part-viewing thing. Its
pretty half-baked right now. Also the project thing. Since I ripped out
the old code from texviewer.vim, project files are absolutely unused. We
should either remove the rest of the code supporting projects or find
some other use for it. There is even a non-function menu item under the
main latex-suite menu called Project which basically does nothing right
now.

Thanks,
Srinath

Re: [Vim-latex-devel] Completion of Tcommands

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

Hi Luc,

> From the outside, it looks like it is (technically) the same thing.
> Thus my question: why not develop only a single generic function that
> can used to insert general-templates, ``macros'' (or even packages ?) ?
> May be I am wrong and you don't have to maintain three times the same
> things -- which differs only by final names and directories.
>
> My idea is that TTemplate, TMacros, ... would invoke the same function
> but with different built-in parameters.
>
As of now, the templates, custom macros and IMAP() functions in
latex-suite are all handled by a central
IMAP_PutTextWithMovement() function with differing arguments and wrapper
functions (for example, TTemplate provides a prompt for the template
files etc). So we do not really repeat any work. The jump function and
marker functionality is all in plugin/imaps.vim.

Also, one sufficiently important implementation issue in the IMAP()
function is that you do not have to bind all expansions to non-keyword
characters like <C-r><space> or <C-r><tab> etc. Most expansions in
latex-suite are for example triggered just as :imaps work except for
being able to correct, no timeout etc. Basically, only the last
character of the first argument of an IMAP() is actually :map'ped to a
LookupCharacter() function. A reverse lookup over previously typed
characters is made whenever such a character is encountered and if there
is a possible completion, it is used... This enables you to have 2-key
mappings like `8 -> \infty which would have been pretty annoying to use
if we had to type 8<C-r><tab> each time...

BTW, very recently I started to have to compile some files multiple
times and therefore quickly felt the need for a function like TKMakeDVI
in tex-tools.vim (part of your latex ftplugin package). I looked at it
and have been extracting parts of it to use in latex-suite. I wish to
borrow the basic logic of the multiple compilations, but I wish to
implement various things like TKFilesDiffer() differently to make it
cross-platform without a lot of platform detection logic... I have a
very rough (and incomplete) draft of this on a non-MAIN branch in the
vim-latex cvs tree. Another implementation issue is that I have a
parallel python implementation of the same thing and the script should
automatically detect python and use the python function instead so all
the things like filediff's etc can be handled via python much more
cleanly than in viml.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/vim-latex/vimfiles/ftplugin/tex/Attic/latexm.vim?rev=1.1.2.3&only_with_tag=latex-multi-compile&content-type=text/vnd.viewcvs-markup

(one big URL)

Thanks,
Srinath

Re: [Vim-latex-devel] Completion of Tcommands

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

Hello,

* On Sun, Jul 13, 2003 at 11:28:28PM +0200, Mikolaj Machowski <mi...@wp...> wrote:
> > BTW, why developping a feature concurrent to templates ? I'm
> > thinking to latexSuite's macros which looks like more restricted
> > templates than the ones we could have with a templates-expander.
> > What did I miss ?
> 
> TTemplate here is a command to source skeleton of file (with various
> \documentclass, preambles, etc.). What you described looks like
> replacement/enhancement for <F5>.

What I described is one of the ways for using µTemplate. (others beeing:
-menus (automatically built), -command :MuTemplate, -autocommand on
BufNewFile). 
The template-expansion function(s) and the search within directories
(visible from 'runtimepath') have been implemented only once.


> Macros and Templates are very similar and created to separate two
> things. Mechanisms are similar (or even the same) but purpose different.

From the outside, it looks like it is (technically) the same thing.
Thus my question: why not develop only a single generic function that
can used to insert general-templates, ``macros'' (or even packages ?) ?
May be I am wrong and you don't have to maintain three times the same
things -- which differs only by final names and directories.

My idea is that TTemplate, TMacros, ... would invoke the same function
but with different built-in parameters.


Cheers,

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

Re: [Vim-latex-devel] Completion of Tcommands

[Mikolaj M. <mi...@wp...>]

On Sat, Jul 12, 2003 at 09:40:09PM +0200, Luc Hermitte wrote:
> Hello,
> * On Sat, Jul 12, 2003 at 07:41:11PM +0200, Mikolaj Machowski <mi...@wp...> wrote:
> > I'd like to add completion of commands similar to those implemented
> > yesterday in TPackage. I would improve usability of Tcommands.
> > Candidates are:
> > 
> > TTemplate 
> BTW, why developping a feature concurrent to templates ? I'm thinking to
> latexSuite's macros which looks like more restricted templates than the
> ones we could have with a templates-expander.
> What did I miss ?

TTemplate here is a command to source skeleton of file (with various
\documentclass, preambles, etc.). What you described looks like
replacement/enhancement for <F5>.

Macros and Templates are very similar and created to separate two
things. Mechanisms are similar (or even the same) but purpose different.

m.

[Vim-latex-devel] vim-latexsuite released as a Debian package

[Mikolaj M. <mi...@wp...>]

Forwarding message from Artur Czechowski:

Hello
I would like to inform you that vim-latexsuite has been released as a Debian
package. It is available in sid (unstable). If you want to know more about
this package in Debian look at:
http://packages.qa.debian.org/v/vim-latexsuite.html
There are important links about status of the package.
There is also possibility to receive information about package by email.
On the same page you have an interface to subscribe.
I will plan to make an unofficial backport for current stable (woody)
to give opportunity of use of this package to more users. Drop me a note
if you want to be informed about it.
Thank you for this great software
	Artur
PS. Please, concern this information as public and notify interested
    people on users mailing list if you like it.
-- 
 Artur R. Czechowski <ar...@he...>