Re: ruby.vim does not work with greater than rubygems 1.7

Re: ruby.vim does not work with greater than rubygems 1.7

Re: Adding events for completefunc

Re: Adding events for completefunc

Re: Adding events for completefunc

Re: Adding events for completefunc

Re: RFC: Shipping parts of vimerl (Erlang addon for Vim) with Vim

> So, I'm probably dropping the pure Vim indent and taking the new one
> in Erlang for Vimerl. This Erlang indenter isn't gonna be included in
> the official Vim distribution, so that Csaba should keep his version
> if he can mantain it. As it seems a good default one for Vim.

I hope you can make it work like the Erlang indentation of Emacs,
which seems to be the de facto standard for indenting Erlang code :)

>> About the syntax file: The syntax file in vimerl was written by Oscar
>> Hellström from scratch AFAIK, so it is quite different from the syntax
>> file currently in Vim (written originally by Kresimir Marzic and is
>> now maintained by me). I would advise against replacing the syntax
>> file, because changing the Erlang syntax highlight drastically would
>> be a negative user experience. The two files could be compared though
>> and the current Vim version could be improved by ideas from the other.
>
> I have the impression (maybe wrong) that the syntax file from Oscar is
> more complete, but it's your call Csaba 

Oscar's file indeed contains some things that could (should) be
incorporated into the current one; but their styles are also
different. For example the current one highlights the global calls
(module:function) and does not highlight local calls or variables;
while Oscar's file highlights variables and not function calls. Both
are good algorithms, but I don't think we should change from one style
to the other in the standard Vim distribution.

> The variable `g:erlang_folding' controls if the specific folding for
> Erlang is enabled. I did this because it's what I saw in most of the
> plugins distributed with Vim. I'm fine with any solution as long as it
> is the most standard one. Also I recently removed a lot of code from
> folding to keep as simple as possible[4].
>
> [4] https://github.com/jimenezrick/vimerl/blob/master/ftplugin/erlang.vim

I examined the version packaged by Per, which was version 1.1.1. But
since then you have released 1.2, and that new version does actually
contain the `g:erlang_folding'  variable, which perfectly solves the
problem that I pointed out.

Whether that or the even newer version ([4] above) should be used,
that is your call, Ricardo :)

>> 2. Remove this line:
>>
>>       setlocal omnifunc=erlang_complete#Complete"

Also, there is a similar problem in the ftplugin file with calling
":compiler erlang". If there is no compiler/erlang.vim, that gives an
error.

>>   If we don't add autoload/erlang_complete.vim, which actually implements this
>>   function, this function should not be used.
>
> OK, but maybe this could be automatically set at runtime. Detecting if
> erlang_complete.vim exists or something like that...

I haven't found an easy solution. The autoload functionality in Vim
will try to look up the file (autoload/erlang_complete.vim in this
case) in each directory in 'runtimepath', but you cannot ask in
advance whether a file exists in any of these directories or not.

One option is to parse the value of 'runtimepath' and check the
existence of the files ourselves -- I would rather not do that.

Another option is to call erlang_complete#Complete and examine the
error. If we get "E117 Unknown function" error, then the file does not
exist; otherwise we are just calling the function in a wrong way
(without arguments).

    silent! call erlang_complete#Complete()
    if strpart(v:errmsg, 0, 4) != 'E117' " E117: Unknown function
        compiler erlang
        setlocal omnifunc=erlang_complete#Complete
    endif

Maybe the third option is the simplest: not to have these two lines in
the version of ftplugin shipped with Vim. (Although I know that it is
worse from a version contol point of view.)

Any of these solutions is fine for me, but something has to be done,
otherwise the "compiler error" line will give an error when opening an
Erlang file and the "omnifunc" line will give an "Unknown function"
error when typing i_C-x_C-o.

Regards,
Csaba

--

-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

cfile autocmd

Dear Bram and Vim_Dev,

I attach a patch which adds the following commands to QuickFixCmdPre and
QuickFixCmdPost autocmds groups: :cfile, :cgetfile, :caddfile, :lfile,
:lgetfile, :laddfile.

The reason is that for some compilers (for example LaTeX) the error file is
not easily readable by vim using errorformat. With this patch using
QuickFxCmdPost, one can write a script which rewrites the log file in a vim
readable way.

The attached patch contains also changes to the description of QuickFixCmdPre
in the doc.

Best regards,
Marcin Szamotulski

-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

diff -r d3cf98aa1619 runtime/doc/autocmd.txt
--- a/runtime/doc/autocmd.txt	Sat Jan 28 18:03:35 2012 +0100
+++ b/runtime/doc/autocmd.txt	Wed Feb 01 11:11:42 2012 +0000
 <at>  <at>  -700,7 +700,9  <at>  <at> 
 				|:lmake|, |:grep|, |:lgrep|, |:grepadd|,
 				|:lgrepadd|, |:vimgrep|, |:lvimgrep|,
 				|:vimgrepadd|, |:lvimgrepadd|, |:cscope|,
-				|:helpgrep|, |:lhelpgrep|).
+				|:cfile|, |:cgetfile|, |:caddfile|, |:lfile|,
+				|:lgetfile|, |:laddfile|, |:helpgrep|,
+				|:lhelpgrep|).
 				The pattern is matched against the command
 				being run.  When |:grep| is used but 'grepprg'
 				is set to "internal" it still matches "grep".
diff -r d3cf98aa1619 src/quickfix.c
--- a/src/quickfix.c	Sat Jan 28 18:03:35 2012 +0100
+++ b/src/quickfix.c	Wed Feb 01 11:11:42 2012 +0000
 <at>  <at>  -2999,7 +2999,23  <at>  <at> 
     if (eap->cmdidx == CMD_lfile || eap->cmdidx == CMD_lgetfile
 	|| eap->cmdidx == CMD_laddfile)
 	wp = curwin;
-
+#ifdef FEAT_AUTOCMD
+    char_u	*au_name = NULL;
+    switch (eap->cmdidx)
+    {
+	case CMD_cfile:	    au_name = (char_u *)"cfile"; break;
+	case CMD_cgetfile:  au_name = (char_u *)"cgetfile"; break;
+	case CMD_caddfile:  au_name = (char_u *)"caddfile"; break;
+	case CMD_lfile:	    au_name = (char_u *)"lfile"; break;
+	case CMD_lgetfile:  au_name = (char_u *)"lgetfile"; break;
+	case CMD_laddfile:  au_name = (char_u *)"laddfile"; break;
+	default: break;
+    }
+    if (au_name != NULL)
+    {
+	apply_autocmds(EVENT_QUICKFIXCMDPRE, au_name, NULL, FALSE, curbuf);
+    }
+#endif
 #ifdef FEAT_BROWSE
     if (cmdmod.browse)
     {
 <at>  <at>  -3035,6 +3051,12  <at>  <at> 
 	    qi = GET_LOC_LIST(wp);
 	qf_jump(qi, 0, 0, eap->forceit);	/* display first error */
     }
+#ifdef FEAT_AUTOCMD
+    if (au_name != NULL)
+    {
+	apply_autocmds(EVENT_QUICKFIXCMDPOST, au_name, NULL, FALSE, curbuf);
+    }
+#endif
 }

 /*

Re: Issue 50 in vim: tex.vim does not understand IEEEeqnarray environment

vim <at> googlecode.com wrote:
> Status: New
> Owner: ----
> Labels: Type-Defect Priority-Medium
>
> New issue 50 by asom... <at> gmail.com: tex.vim does not understand 
> IEEEeqnarray environment
> http://code.google.com/p/vim/issues/detail?id=50
>
> What steps will reproduce the problem?
> 1. Open a LaTeX document that uses IEEEeqnarray
> 2. Enter this string: \begin{IEEEeqnarray}{rCl}x_0 & = & 
> x_1\end{IEEEeqnarray}
> 3. Notice that the underscores are highlighted as errors
> [snip]
> Attachments:
>     tex.vim.patch  975 bytes
>
In addition, may I point out that in  :help tex-package there's a 
comment about posting extension support:

   "Please consider uploading any extensions that you write, which 
typically would go in $HOME/after/syntax/tex/[pkgname].vim, to 
http://vim.sf.net/"

You should change your patch into such an extension support bit, having 
the code go into

   .vim/after/syntax/tex/IEEEeqnarray.vim

could be helpful to others.

Regards,
Chip Campbell

--

-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Subject: vimgrep fails when 'autochdir' is set

vimgrep fails when 'autochdir' is set

Trying to grep an entire project tree fails with autochdir set:

gvim -N -u NONE -i NONE C:/path/to/project/dir/relative/path/in/
project/somedir/file.c
set autochdir
cd C:/path/to/project/dir
vimgrep /pattern/j relative/path/in/project/**/*.[ch]

Gives:
C:\path\to\project\dir
"relative\path\in\project\somedir\file.c" [New DIRECTORY]
C:\path\to\project\dir
"relative\path\in\project\somedir\file2.c" [New DIRECTORY]
C:\path\to\project\dir
"relative\path\in\project\somedir\file3.c" [New DIRECTORY]
...
E480: No match: pattern

But without the set autochdir, the vimgrep correctly finds all
occurrences of pattern in the project.

I'm about 95% sure this worked at some point in the past, because this
is how I've done similar searches before.

I actually found the problem while using :ProjectGrep in eclim, but
discovered that even with the minimal configuration given above, Vim
seems to use the wrong directory as the base for its grep search.

VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Dec  9 2011 16:21:55)
MS-Windows 32-bit GUI version with OLE support
Included patches: 1-372
Compiled by digitectNO <at> SPAMdancingpaper.com
Huge version with GUI.  Features included (+) or not (-):

--

-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php