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

[Vim-latex-devel] vim vs. gvim when compiling

[Patrick S. <pa...@st...>]

Hi,

I noticed a strange behaviour in my current vimlatex in Arch Linux. I have
set the compile target to pdf and added pdf to the multi compile list.
When I compile a document from vim this works fine, but when I use gvim it
only compiles once. Right now it even decided to only run bibtex.

The installation I have was copied from an Ubuntu box where all works
fine. I also have it set up in windows xp at work with the same settings,
without any problems.

Any idea on what might be the culprit here?

Regards,
Patrick

[Vim-latex-devel] vim vs. gvim when compiling

[Patrick S. <pa...@st...>]

Hi,

I noticed a strange behaviour in my current vimlatex in Arch Linux. I have
set the compile target to pdf and added pdf to the multi compile list.
When I compile a document from vim this works fine, but when I use gvim it
only compiles once. Right now it even decided to only run bibtex.

The installation I have was copied from an Ubuntu box where all works
fine. I also have it set up in windows xp at work with the same settings,
without any problems.

Any idea on what might be the culprit here?

Regards,
Patrick

[Vim-latex-devel] [ vim-latex-Bugs-3137564 ] Forward Search broken in windows

[SourceForge.net <no...@so...>]

Bugs item #3137564, was opened at 2010-12-15 01:39
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=466456&aid=3137564&group_id=52322

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Forward Search broken in windows

Initial Comment:
Need to replace line 359 of compiler.vim with following line to fix forward search

+	if (has('win32') && (viewer == "yap -1" || viewer == "YAP -1" || viewer == "Yap -1"))
-	if (has('win32') && (viewer == "yap" || viewer == "YAP" || viewer == "Yap"))

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=466456&aid=3137564&group_id=52322

[Vim-latex-devel] [ vim-latex-Bugs-3137490 ] includegraphics and psfig filename completion doesn't work

[SourceForge.net <no...@so...>]

Bugs item #3137490, was opened at 2010-12-14 23:04
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=466456&aid=3137490&group_id=52322

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: includegraphics and psfig filename completion doesn't work

Initial Comment:
The bug described below with patch has not be fixed as a result filename completion for psfig and includegraphics is broken:
http://www.mail-archive.com/vim...@li.../msg00505.html

Additional bug is on line 145

+		elseif exists("s:type") && (s:type == 'includegraphics' || s:type == 'psfig') 
- 		elseif exists("s:type") && (s:type ~= 'includegraphics' || s:type == 'psfig') 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=466456&aid=3137490&group_id=52322

Re: [Vim-latex-devel] Error on <F5> map when add babel package

[Andreas W. <And...@em...>]

Hi all,

* Robson Roberto Souza Peixoto dixit [091110 16:54]:
> I'd try to added the package babel using the <F5>, but the latex-suite added 
> the line below
>
> <++>]{babel}``usepackage[X
>
> The same for fixme
>
> <++>]{fixme}``usepackage[X

I had the same thing happening (but also for other packages) and have noticed that the menu where one could 
choose packages was not starting with what I expected. Both types of behaviour went away when I removed a 
html file ("supporting a package.html") that had been residing in my ~/.vim/ftplugin/latex-suite/packages 
directory. Maybe you have an irregular file in the package dir, too?

Andreas


-- 
Dr. Andreas Wagner
Goethe-Universität Frankfurt
http://tinyurl.com/awagner
Tel. +49 (0)69/798-22765

Exzellenz-Cluster "The Formation of Normative Orders"
http://www.normativeorders.net/
Senckenberganlage 31, R. 517, Postfach 40
60325 Frankfurt am Main

Institut für Philosophie
Grüneburgplatz 1, R. 2.456
60629 Frankfurt am Main

[Vim-latex-devel] Jumping to error location is not working

[andreas <an...@ge...>]

Hi,

first of all i would like to thank you for this nice vim plugin. But i
have one issue that i can't solve.

When i go through the tutorial, i stop at 8.1 Debuggin LaTeX source
files. Using \ll is working fine and i get the two errors in the Error
List window and when i cycle through the errors the Log Preview window
is shown, too. But when i'm on one of the errors in the Error List
window and i press <enter> the cursor is not jumping to the location of
the error as explained in the tutorial.
I tried to use a clean vim, so just vim latexsuite is installed with the
recommendations for the .vimrc in the documentation and nothing else,
but it's still not working.
Tex_GotoError is not set to 0, i also tried setting it to 1 in the
tex.vim but didn't help.
I also tried gvim and vim on another system, same problem.
My vim version is 7.2.442 and latexsuite is 1.8.23.20100129 and i'm
runinng gentoo, but same error with Debian sid unstable.

Do you have any idea?

I read that this problem occured one year ago, but no one did answer to
this thread:

http://www.mail-archive.com/vim...@li.../msg00622.html

Thanks

Andi++

[Vim-latex-devel] Muhammad Najmi Ahmad Zabidi invited you to Dropbox

[Dropbox <no-...@dr...>]

Muhammad Najmi Ahmad Zabidi wants you to use Dropbox to sync and share files online and across computers.

Get started here: http://www.dropbox.com/link/20.I6QggyaV5h/NjQ3OTU3MDAyNw?src=referrals_bulk

- The Dropbox Team

____________________________________________________ 
To stop receiving invites from Dropbox, please go to http://www.dropbox.com/bl/c7fab8f0b302/vim-latex-devel%40lists.sourceforge.net

[Vim-latex-devel] insert-mode mapping for BibTex

[Chuck Pepe-R. <cp...@mi...>]

I recently installed vim-latex and I can't seem to get the insert-mode
mappings to work for BibTex entries.  The other insert-mode mappings are
working perfectly and I'm not sure where to begin to troubleshoot my issue.
 Thank you.
- Chuck

[Vim-latex-devel] [ vim-latex-Patches-3057689 ] IMAP with mulitbyte lhs

[SourceForge.net <no...@so...>]

Patches item #3057689, was opened at 2010-09-01 21:23
Message generated for change (Comment added) made by lux-vim-latex
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=466458&aid=3057689&group_id=52322

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: LuX (lux-vim-latex)
Assigned to: Nobody/Anonymous (nobody)
Summary: IMAP with mulitbyte lhs

Initial Comment:
The IMAP function, which comes with the latex-suite in the plugin imaps.vim, deals wrongly with multibyte left hand side (so-called lhs). The attached patch fixes this. 

Version number:
imaps.vim 997 2006-03-20 09:45:45Z srinathava $
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Dec  1 2008)

Example: 
You want to chain IMAP mapping, as follows: 
        call IMAP("\\subset", "⊂", "")
        call IMAP("⊂eq", "⊆", "")
Type "1234\subset", you see "1234⊂" (good). But if you add "eq", you see "12⊆" (bad) instead of "1234⊆".

Description:
The attached patch adds to imaps.vim two functions called s:MultiByteStrlen and s:MultiByteStrpart, analogous to Vim's functions strlen and strpart but which deal with strings character per character instead of byte per byte. Every call to strlen and strpart is then replaced by a call to these variants, and as far as I can see it solved the problem. 

----------------------------------------------------------------------

>Comment By: LuX (lux-vim-latex)
Date: 2010-11-14 22:40

Message:
> tmaas wrote:
> This change looks wrong:
> @@ -194,7 +194,7 @@
[..]
> Are you sure this is correct? I guess the new line needs to be:
> + let char = s:MultiByteStrpart(a:lhs,s:MultiByteStrlen(a:lhs)-1)

Yes, you're right, of course. Sorry about that. 

----------------------------------------------------------------------

Comment By: Till Maas (tmaas)
Date: 2010-10-28 22:37

Message:
This change looks wrong:
@@ -194,7 +194,7 @@
 "
 " Added mainly for debugging purposes, but maybe worth keeping.
 function! IMAP_list(lhs)
-	let char = a:lhs[strlen(a:lhs)-1]
+ 	let lastLHSChar = s:MultiByteStrpart(a:lhs,s:MultiByteStrlen(a:lhs)-1)
 	let charHash = s:Hash(char)
 	if exists("s:LHS_" . &ft ."_". charHash) && a:lhs =~
s:LHS_{&ft}_{charHash}
 		let ft = &ft

Are you sure this is correct? I guess the new line needs to be:
+ 	let char = s:MultiByteStrpart(a:lhs,s:MultiByteStrlen(a:lhs)-1)

----------------------------------------------------------------------

Comment By: LuX (lux-vim-latex)
Date: 2010-09-06 19:53

Message:
Sorry, it appeared to me that the previously attached patch was not correct
(I did not apply 'diff' to the right files). But most of all the strategy
of changing every call to strlen and strpart by my s:MultiByte* variants is
not good: in some case, it is really strpart or strlen which must be used.


Example: 
The following command appears 3 times in imaps.vim: 
        strpart(getline(".", 0, col(".")-1)
What is expected is the content of the current line before the cursor.
Since col(".") returns the number of bytes, not of characters, until the
first byte (not the last one) of the character under the cursor, col(".")-1
is just the number of bytes in the current line before the cursor. Thus
strpart will return what expected, and MultiByteStrpart will not (not
always).

So this time I have looked carefully at every place in imps.vim where
strlen and strpart were used, and I changed them to there
s:MuliByte-variants ONLY when I was sure that it was needed (I left strlen
and strpart also when it did not make any difference to use them or
s:MultiByte*, for example when they are called only to test wether or not a
string is empty). 

The result of this better strategy is the attached patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=466458&aid=3057689&group_id=52322

[Vim-latex-devel] Next snapshot?

[Mario S. <ma...@ma...>]

When will you provide new snapshot of vim-latex?
Should be revision 1115?

Can I help in some way?

Thank you very much
-- 
Mario Santagiuliana
www.marionline.it

[Vim-latex-devel] Error on <F5> map when add babel package

[Robson R. S. P. <rob...@gm...>]

I'd try to added the package babel using the <F5>, but the latex-suite added
the line below

<++>]{babel}``usepackage[X

The same for fixme

<++>]{fixme}``usepackage[X


Thanks

Re: [Vim-latex-devel] eacute input on a mac in latex-suite

[Sébastien B. <bar...@cr...>]

> The FAQ ;-)

Great, that fixed it. Thank you.

Re: [Vim-latex-devel] eacute input on a mac in latex-suite

[Christian E. <bla...@gm...>]

* Sébastien Barthélemy on Saturday, November 06, 2010 at 11:52:38 +0100
> I'm using vim and macvim (both from macports) on a mac os computer
> with an english keyboard. In order to input an eacute (é) character, I
> use the standard mac sequence : option+e e
> 
> In vim, it works as expected. When I press option+e, it inserts a ´
> character with a yellow background, then when I press e, it is
> replaced with é.
> 
> In MacVim, it works in insert mode, but it does not if I want to
> replace a character. Say I want to replace the character under the
> cursor with é, the option+e e sequence will do it in vim, but in
> MacVim the character will be replaced by ´ instead of é. I have the
> same problem if I want to replace the character with ú (option+e u).
> 
> This is happening while editing plain text file. For latex files, with
> vim-latex-mode active, there is additional problem: I cannot insert
> (in insert mode) the é character. When I press option+e, ´ is
> inserted, then when I press e it is removed. This happens in both vim
> and macvim. But it works for ú !
> 
> This last problem is the most annoying.
> 
> Does anybody here have a suggestion?

The FAQ ;-)

http://vim-latex.sourceforge.net/index.php?subject=faq&title=FAQ#faq-e-acute

c
-- 
theatre - books - texts - movies
Black Trash Productions at home: http://www.blacktrash.org
Black Trash Productions on Facebook:
http://www.facebook.com/blacktrashproductions

[Vim-latex-devel] eacute input on a mac in latex-suite

[Sébastien B. <bar...@cr...>]

Hello,

I'm using vim and macvim (both from macports) on a mac os computer
with an english keyboard. In order to input an eacute (é) character, I
use the standard mac sequence : option+e e

In vim, it works as expected. When I press option+e, it inserts a ´
character with a yellow background, then when I press e, it is
replaced with é.

In MacVim, it works in insert mode, but it does not if I want to
replace a character. Say I want to replace the character under the
cursor with é, the option+e e sequence will do it in vim, but in
MacVim the character will be replaced by ´ instead of é. I have the
same problem if I want to replace the character with ú (option+e u).

This is happening while editing plain text file. For latex files, with
vim-latex-mode active, there is additional problem: I cannot insert
(in insert mode) the é character. When I press option+e, ´ is
inserted, then when I press e it is removed. This happens in both vim
and macvim. But it works for ú !

This last problem is the most annoying.

Does anybody here have a suggestion?

Thanks in advance,
Sebastian

Re: [Vim-latex-devel] bracket "}" is highlighted after inserting template

[Till M. <ope...@ti...>]

On Fri, Oct 29, 2010 at 06:17:11AM -0400, peng shao wrote:
> Hi.  Thank you for paying attention to my problem. I am using VIM 7.3 and
> vim-latex-1.8.23-20101027-r1112 under gentoo. There is an annoying problem
> that I couldn't fix for a very long time since several years ago I started
> using latex-suite: every time if I use :TTemplate command to choose SOME
> template, then the bracket } is highlighted automatically in the inserted
> template. It looks like this symbol is searched when I insert the template.

In case someone else wants to debug this: Here it cannot be reproduced
with any template from vim-latex except the IEEEtran template (the
article, report and report_two_column templates do not show this
problem.

Regards
Till

[Vim-latex-devel] bracket "}" is highlighted after inserting template

[peng s. <sha...@gm...>]

Hi.  Thank you for paying attention to my problem. I am using VIM 7.3 and
vim-latex-1.8.23-20101027-r1112 under gentoo. There is an annoying problem
that I couldn't fix for a very long time since several years ago I started
using latex-suite: every time if I use :TTemplate command to choose SOME
template, then the bracket } is highlighted automatically in the inserted
template. It looks like this symbol is searched when I insert the template.

I have modified my .vimrc to the minimum to rule out any possible incorrect
customized command but had no luck. What is even more annoying is that some
templates don't have this problem while some do, for example the "IEEEtran"
template highlights } automatically while the "article" template is fine.

I guess it may have something to do with certain special words/expressions
in the template, but I could not find any pattern. The only thing I know is
if I remove all <++> stuffs from any template then it is by far working
fine....

This problem is really annoying and I wish it could be solved... Thank you
:)

Peng

[Vim-latex-devel] [ vim-latex-Patches-3057689 ] IMAP with mulitbyte lhs

[SourceForge.net <no...@so...>]

Patches item #3057689, was opened at 2010-09-01 21:23
Message generated for change (Comment added) made by tmaas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=466458&aid=3057689&group_id=52322

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: LuX (lux-vim-latex)
Assigned to: Nobody/Anonymous (nobody)
Summary: IMAP with mulitbyte lhs

Initial Comment:
The IMAP function, which comes with the latex-suite in the plugin imaps.vim, deals wrongly with multibyte left hand side (so-called lhs). The attached patch fixes this. 

Version number:
imaps.vim 997 2006-03-20 09:45:45Z srinathava $
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Dec  1 2008)

Example: 
You want to chain IMAP mapping, as follows: 
        call IMAP("\\subset", "⊂", "")
        call IMAP("⊂eq", "⊆", "")
Type "1234\subset", you see "1234⊂" (good). But if you add "eq", you see "12⊆" (bad) instead of "1234⊆".

Description:
The attached patch adds to imaps.vim two functions called s:MultiByteStrlen and s:MultiByteStrpart, analogous to Vim's functions strlen and strpart but which deal with strings character per character instead of byte per byte. Every call to strlen and strpart is then replaced by a call to these variants, and as far as I can see it solved the problem. 

----------------------------------------------------------------------

>Comment By: Till Maas (tmaas)
Date: 2010-10-28 22:37

Message:
This change looks wrong:
@@ -194,7 +194,7 @@
 "
 " Added mainly for debugging purposes, but maybe worth keeping.
 function! IMAP_list(lhs)
-	let char = a:lhs[strlen(a:lhs)-1]
+ 	let lastLHSChar = s:MultiByteStrpart(a:lhs,s:MultiByteStrlen(a:lhs)-1)
 	let charHash = s:Hash(char)
 	if exists("s:LHS_" . &ft ."_". charHash) && a:lhs =~
s:LHS_{&ft}_{charHash}
 		let ft = &ft

Are you sure this is correct? I guess the new line needs to be:
+ 	let char = s:MultiByteStrpart(a:lhs,s:MultiByteStrlen(a:lhs)-1)

----------------------------------------------------------------------

Comment By: LuX (lux-vim-latex)
Date: 2010-09-06 19:53

Message:
Sorry, it appeared to me that the previously attached patch was not correct
(I did not apply 'diff' to the right files). But most of all the strategy
of changing every call to strlen and strpart by my s:MultiByte* variants is
not good: in some case, it is really strpart or strlen which must be used.


Example: 
The following command appears 3 times in imaps.vim: 
        strpart(getline(".", 0, col(".")-1)
What is expected is the content of the current line before the cursor.
Since col(".") returns the number of bytes, not of characters, until the
first byte (not the last one) of the character under the cursor, col(".")-1
is just the number of bytes in the current line before the cursor. Thus
strpart will return what expected, and MultiByteStrpart will not (not
always).

So this time I have looked carefully at every place in imps.vim where
strlen and strpart were used, and I changed them to there
s:MuliByte-variants ONLY when I was sure that it was needed (I left strlen
and strpart also when it did not make any difference to use them or
s:MultiByte*, for example when they are called only to test wether or not a
string is empty). 

The result of this better strategy is the attached patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=466458&aid=3057689&group_id=52322

[Vim-latex-devel] [ vim-latex-Patches-3004790 ] Remove some default error formats (solves bug with revtex4)

[SourceForge.net <no...@so...>]

Patches item #3004790, was opened at 2010-05-20 18:09
Message generated for change (Comment added) made by tmaas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=466458&aid=3004790&group_id=52322

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: johfel (johfel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove some default error formats (solves bug with revtex4)

Initial Comment:
Using revtex4, the version line in the log file is matched by the default error formats of vim. This leads to confusing error messages. 
The attached patch solve this (and comparable problems) by removing the responsible error formats.
The vim-latex code adds comparable, but less error-prone error formats, so that the default error formats are not necessary.

Description: Remove some default error formats.
 The default error patterns, that are removed by this patch, match wrongly version
 messages (for example of revtex4).
 The comparable error formats in compiler/tex.vim are less error-prone.
Author: Johann Felix Soden <jo...@gm...>
Bug-Debian: http://bugs.debian.org/582100

----------------------------------------------------------------------

>Comment By: Till Maas (tmaas)
Date: 2010-10-28 22:21

Message:
applied in changeset 1114, thank you for your patience.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=466458&aid=3004790&group_id=52322

[Vim-latex-devel] [ vim-latex-Patches-3004833 ] Add okular search forward support

[SourceForge.net <no...@so...>]

Patches item #3004833, was opened at 2010-05-20 20:20
Message generated for change (Settings changed) made by tmaas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=466458&aid=3004833&group_id=52322

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Mario Santagiuliana (marionline)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add okular search forward support

Initial Comment:
Add support to search forward in okular with just this example configuration in vimrc:
let g:Tex_CompileRule_dvi='latex -src-specials -interaction=nonstopmode $*'
let g:Tex_ViewRule_dvi = 'okular'

----------------------------------------------------------------------

>Comment By: Till Maas (tmaas)
Date: 2010-10-28 22:10

Message:
commited with small changes in changeset:1113

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=466458&aid=3004833&group_id=52322

Re: [Vim-latex-devel] Labels with spaces fools <F9>

[<pat...@fr...>]

Selon Till Maas <ope...@ti...>:

> On Wed, Oct 27, 2010 at 07:21:41PM +0200, pat...@fr... wrote:
> > Dear vim-latex-devel,
> >
> > As reported in
> > http://permalink.gmane.org/gmane.comp.editors.vim.latex.devel/88
> > if your LaTeX file contains something like
> > \label{section:Important stuff}
> > (note the space between Important and stuff) then \ref{<F9>}
> > will bring a correct outline buffer but when you press Enter on the line
> > section:Important stuff
> > you will get in your original file:
> > \ref{section:Important}
> > instead of the expected
> > \ref{section:Important stuff}
>
> This works for me with this minimal example and SVN revision 1112:
> \documentclass{article}
> \begin{document}
>
> \label{label1nospace}
> \label{label2 space}
> \label{label3nospace}
>
> \ref{
> \end{document}

Hi,

I'm sorry, I haven't been enough specific. My minimal example is

\documentclass{article}
\begin{document}

\section{First section}
\label{label1nospace}

\section{Second one}
\label{label2 space}

\ref{
\end{document}

The (fully unfolded) outline window is

1. First section<<<1
>      label1nospace    </home/pmassot/tmp/test.tex>
:        \section{First section}
2. Second one<<<1
>      label2 space   </home/pmassot/tmp/test.tex>
:        \section{Second one}

Actually I get the expected result when I press enter on the second to last line
but not when I press enter on the last line (which is the one that makes sense
to me).

Best,

Patrick

Re: [Vim-latex-devel] vimlatex and eclim

[Mario S. <ma...@ma...>]

In data 25/10/2010 16:15:28, Mario Santagiuliana ha scritto:
> I found a problem with vimlatex when eclim is installed.
> 
> The problem is similar to this:
> http://permalink.gmane.org/gmane.comp.editors.vim.latex.devel/187
> 
> It is not possible to compile latex file on multiple file projects like
> explain in documentation here:
> http://vim-latex.sourceforge.net/documentation/latex-suite/latex-
> project.html
> 
> Erase .vim/eclim resolve this problem...but eclim is removed.
> Test on elim 1.6.0 and eclipse 3.6.0
> 
> Are there any other solution? I will update eclim...maybe there is not
> trouble in new version...
> 
> I post this issue on eclim mailing list.
> 
> P.S.
> Is there any updates on vim-latex patches?
> http://sourceforge.net/tracker/?group_id=52322&atid=466458
> 
> Thank you


Eric Van Dewoestine (developer of eclim) give the solution:
> Try setting the following variable:
>   :let g:EclimMakeLCD = 0

He also say:
> I'm going to change how that functionality works and white list make
> programs for which an lcd is beneficial so that eclim doesn't end up
> screwing with all the others.

Hope somebody can help him. He is a great developer.
-- 
Mario Santagiuliana
www.marionline.it

Re: [Vim-latex-devel] Labels with spaces fools <F9>

[Till M. <ope...@ti...>]

On Wed, Oct 27, 2010 at 07:21:41PM +0200, pat...@fr... wrote:
> Dear vim-latex-devel,
> 
> As reported in
> http://permalink.gmane.org/gmane.comp.editors.vim.latex.devel/88
> if your LaTeX file contains something like
> \label{section:Important stuff}
> (note the space between Important and stuff) then \ref{<F9>}
> will bring a correct outline buffer but when you press Enter on the line
> section:Important stuff
> you will get in your original file:
> \ref{section:Important}
> instead of the expected
> \ref{section:Important stuff}

This works for me with this minimal example and SVN revision 1112:
\documentclass{article}
\begin{document}

\label{label1nospace}
\label{label2 space}
\label{label3nospace}

\ref{
\end{document}

Regards
Till

Re: [Vim-latex-devel] vim-latex multi compile

[Till M. <ope...@ti...>]

Hi David,

On Wed, Oct 27, 2010 at 03:39:14PM -0400, David Karapetyan wrote:

> I am subscribed to the list--I have been receiving emails from others who are posting to the list. My patches are indeed being withheld in some queue, thanks to their size (max size for emails is 44KB or so). However, even emails with size <44KB are being withheld. Also, why is the project being moved to svn? Don't want to sound like a snob, but git (in conjunction with github) might be a better option; many useful vim scripts are already located there. As a test, I have cc'd this message to the list; unless a miracle occurs, it shouldn't go through.

I only see your huge mail in the moderation queue. Can you please resend
your changes with one diff for each logical change? E.g. use git
locally with one commit per change and then use git format-patch to
create the patches. Please also use proper commit messages that help to
understand what the patches are supposed to do and what problem they
solve.

vim-latex will eventually move to git instead of svn, if you want to
speed this up, you can provide me with a well tested set of commands to
properly migrate the svn repository.

Regards
Till

Re: [Vim-latex-devel] vim-latex multi compile

[David K. <dav...@gm...>]

Dear Ted,

I am subscribed to the list--I have been receiving emails from others who are posting to the list. My patches are indeed being withheld in some queue, thanks to their size (max size for emails is 44KB or so). However, even emails with size <44KB are being withheld. Also, why is the project being moved to svn? Don't want to sound like a snob, but git (in conjunction with github) might be a better option; many useful vim scripts are already located there. As a test, I have cc'd this message to the list; unless a miracle occurs, it shouldn't go through.

--
Best,
David Karapetyan
http://davidkarapetyan.com
University of Notre Dame
Department of Mathematics
255 Hurley Hall
Notre Dame, IN 46556-4618
Phone: 574-631-5706
Cell:  202-460-5173
Fax:   574-631-6579


On Oct 27, 2010, at 3:35 PM, Ted Pavlic wrote:

> David --
> 
> You may need to be subscribed to the list. I've received messages as recently as today from the list. Perhaps your messages are behind held in some moderator queue somewhere...
> 
> --Ted
> 
> On 10/27/2010 03:28 PM, David Karapetyan wrote:
>> Dear Ted,
>> 
>> Actually, I have been sending messages vim...@li.... I don't know why my messages are not showing up. Thank you for the workarounds as well.
>> 
>> --
>> Best,
>> David Karapetyan
>> http://davidkarapetyan.com
>> University of Notre Dame
>> Department of Mathematics
>> 255 Hurley Hall
>> Notre Dame, IN 46556-4618
>> Phone: 574-631-5706
>> Cell:  202-460-5173
>> Fax:   574-631-6579
>> 
>> 
>> On Oct 27, 2010, at 2:17 PM, Ted Pavlic wrote:
>> 
>>> David --
>>> 
>>> 	By the way, I didn't see any of your messages show up on the vim-latex-devel list, which makes me think you're sending to the main vim-devel list, which is the wrong list to use. That also explains why you haven't seen much vim-latex-devel activity.
>>> 
>>> 	You need to look into this list:
>>> 
>>> vim...@li...
>>> 
>>> You also need to post your patches (with "PATCH" in the subject) to that list. You can find subscription information at:
>>> 
>>> https://lists.sourceforge.net/lists/listinfo/vim-latex-devel
>>> 
>>> As you'll see, that list is actually moderately active.
>>> 
>>> 	I also recommend that you use SVN to download the development version of the vim-latex suite. Several patches have been applied since the previous release.
>>> 
>>> 	Best --
>>> 	Ted
>>> 
>>> On 10/27/2010 11:41 AM, Ted Pavlic wrote:
>>>> David --
>>>> 
>>>> I've taken a look, and I think that multiply defined labels are going to
>>>> be a bit of a problem regardless of what approach you take. It is true
>>>> that latex gives a warning in the TeX file for multiply defined labels,
>>>> but it also gives a warning in the AUX. That is, gvim is arguably not
>>>> screwing anything up because it is opening the file that LaTeX tells it
>>>> it should be opening up (I do have a workaround; see below).
>>>> 
>>>> On the first LaTeX pass through your TeX, it generates the AUX. On the
>>>> second pass, it incorporates information accumulated in the AUX. It is
>>>> on that pass through the AUX that generates the error, and that's why
>>>> LaTeX reports that the AUX is the problem (as opposed to the TeX).
>>>> 
>>>> There are three workarounds:
>>>> 
>>>> *) Press CTRL-O to bring you back to your TeX file after TeX opens a new
>>>> buffer with the AUX in it (you can also :bd to delete the AUX buffer,
>>>> but then you'll be placed in the quickfix window, and you'll have to :bd
>>>> that to get back to TeX).
>>>> 
>>>> *) You can tell Vim-LaTeX to ignore these warnings entirely. Take a look
>>>> at:
>>>> 
>>>> :help Tex_IgnoredWarnings
>>>> 
>>>> to see how you can set the configuration variable g:Tex_IgnoredWarnings.
>>>> As it asys, you must also make sure you adjust g:Tex_IgnoreLevel
>>>> accordingly. You can add a string that matches the multiple-label
>>>> warning string, and if Vim sees that TeX is throwing that error, it will
>>>> not take any action.
>>>> 
>>>> *) To turn off the "goto error" feature of Vim-LaTeX so it doesn't try
>>>> to open up the source of the first error automatically. You're supposed
>>>> to be able to use:
>>>> 
>>>> :set g:Tex_GotoError=0
>>>> 
>>>> but right now, it doesn't appear like that is working... at least not in
>>>> the toy example I have setup.
>>>> 
>>>> So CTRL-O might be your best bet. :-/
>>>> 
>>>> --Ted
>>>> 
>>>> 
>>>> On 10/27/2010 12:16 AM, David Karapetyan wrote:
>>>>> Dear Ted,
>>>>> 
>>>>> Following your suggestions (regarding the .aux file being barfed onto
>>>>> the screen after a multiple compilation) does not fix the problem. I
>>>>> am currently on a Mac, and was curious if you were having the same
>>>>> problems. I have also submitted my patch to the vim-developers list
>>>>> with the "PATCH" subject line, per your suggestion.
>>>>> 
>>>>> --
>>>>> Best,
>>>>> David Karapetyan
>>>>> http://davidkarapetyan.com
>>>>> University of Notre Dame
>>>>> Department of Mathematics
>>>>> 255 Hurley Hall
>>>>> Notre Dame, IN 46556-4618
>>>>> Phone: 574-631-5706
>>>>> Cell: 202-460-5173
>>>>> Fax: 574-631-6579
>>>>> 
>>>>> On Oct 24, 2010, at 9:30 PM, Ted Pavlic wrote:
>>>>> 
>>>>>> David --
>>>>>> 
>>>>>>> I would have emailed the vim-latex developers list, but they are
>>>>>>> notoriously slow at replying (even when I send patches and bug fixes
>>>>>>> in). Is the vim-latex project even being maintained?
>>>>>> 
>>>>>> Till Maas does as best as he can. Usually if you post a message to
>>>>>> the list with "PATCH" or "[PATCH]" in the subject, it will get his
>>>>>> attention. I know he's been wanting to convert the repo from svn to
>>>>>> Mercurial to aid in the easy management of the project and inclusion
>>>>>> of more developers... but he just hasn't had the time (and is a
>>>>>> little worried about the process) to do the conversion.
>>>>>> 
>>>>>>> I wanted to ask you about a bug with vim-latex compilation that I
>>>>>>> cannot resolve. If the multicompile option is set for pdfs, vim-latex
>>>>>>> will barf the .aux file onto my screen (displacing whatever source
>>>>>>> code I am editing) whenever I have a duplicate label in my tex source
>>>>>>> code. How can I disable this "feature"?
>>>>>> 
>>>>>> I have a FEELING that the problem is the standard problem that Vim's
>>>>>> compiler error code has with the default way LaTeX generates error
>>>>>> messages. That is, rather than a normal compiler that would say
>>>>>> something like...
>>>>>> 
>>>>>> gcc: missing blah on line 5 in file myfile.c
>>>>>> 
>>>>>> LaTeX does something like...
>>>>>> 
>>>>>> (myfile.c
>>>>>> # lots
>>>>>> # of
>>>>>> # OK
>>>>>> # messages
>>>>>> error: line 5: missing blah
>>>>>> # other
>>>>>> # messages
>>>>>> )
>>>>>> 
>>>>>> and to make matters worse, these things get nested... and sometimes
>>>>>> all of the closures happen on the same line... This really confuses
>>>>>> Vim. The usual symptom is that Vim picks the wrong file to open when
>>>>>> showing you an error. There is a way to get LaTeX to generate error
>>>>>> messages in the conventional format, but it still breaks warning
>>>>>> messages. So you have to take a different approach.
>>>>>> 
>>>>>> See a post I put together a long time ago at:
>>>>>> 
>>>>>> http://phaseportrait.blogspot.com/2008/03/fixing-vim-latex-compiler-error.html
>>>>>> 
>>>>>> 
>>>>>> I give a description of the problem and many of the known fixes. I
>>>>>> recommend you try at least one of them if not more. In most cases,
>>>>>> using my "vimlatex" pipe script in front of your usual LaTeX build
>>>>>> line will do its best to "sanitize" the LaTeX error messages for Vim.
>>>>>> 
>>>>>> (however, if the "rubber" Python script is a very nice LaTeX make
>>>>>> frontend, and it can also sanitize error and warning messages without
>>>>>> too much effort)
>>>>>> 
>>>>>>> I have various patch files for vim-latex that fix a number of bugs it
>>>>>>> has when used on macosx (using the MacVim editor and Skim pdf
>>>>>>> viewer). If you are interested, I can send them to you.
>>>>>> 
>>>>>> I do have commit access to the SVN repo, but I just haven't had much
>>>>>> time. I really strongly recommend that you post the patches to the
>>>>>> vim-latex-devel list with "PATCH" or "[PATCH]" in the subject. They
>>>>>> will likely get committed in a week or two when Till goes through and
>>>>>> does house cleaning. I've seen several new commits in the
>>>>>> not-too-distant past.
>>>>>> 
>>>>>> I hope that helps!
>>>>>> 
>>>>>> Best --
>>>>>> Ted
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Ted Pavlic<te...@te...>
>>>>>> 
>>>>>> Please visit my 2010 d'Feet ALS walk page:
>>>>>> http://web.alsa.org/goto/tpavlic
>>>>>> My family appreciates your support in the fight to defeat ALS.
>>>>> 
>>>>> 
>>>> 
>>> 
>>> --
>>> Ted Pavlic<pav...@os...>  -- NSF CPS Postdoctoral Researcher
>>> Computer Science and Engineering, The Ohio State University
>>> 395 Dreese Laboratories, 2015 Neil Ave., Columbus, OH 43210
>>> 
>>>  Please visit my 2010 d'Feet ALS walk page:
>>>        http://web.alsa.org/goto/tpavlic
>>>  My family appreciates your support in the fight to defeat ALS.
>> 
> 
> -- 
> Ted Pavlic <pav...@os...> -- NSF CPS Postdoctoral Researcher
> Computer Science and Engineering, The Ohio State University
> 395 Dreese Laboratories, 2015 Neil Ave., Columbus, OH 43210
> 
>  Please visit my 2010 d'Feet ALS walk page:
>        http://web.alsa.org/goto/tpavlic
>  My family appreciates your support in the fight to defeat ALS.

[Vim-latex-devel] Labels with spaces fools <F9>

[<pat...@fr...>]

Dear vim-latex-devel,

As reported in
http://permalink.gmane.org/gmane.comp.editors.vim.latex.devel/88
if your LaTeX file contains something like
\label{section:Important stuff}
(note the space between Important and stuff) then \ref{<F9>}
will bring a correct outline buffer but when you press Enter on the line
section:Important stuff
you will get in your original file:
\ref{section:Important}
instead of the expected
\ref{section:Important stuff}

I wouldn't have expected LaTeX to like labels containing spaces until
one of my collaborators used some and LaTeX liked them!

The problem in vim-latex is in file
$VIM/addons/ftplugin/latex-suite
which contains the function Tex_FinishOutlineCompletion. The faulty
regex is in the line
let ref_complete = matchstr(getline('.'), '^>\s\+\zs\S\+\ze')

I've replaced it with
let ref_complete = matchstr(getline('.'), '^>\s\+\zs[^<\t]\+\ze')
which works for me but I don't say this is a well thought out solution.

Best,

Patrick Massot