Re: Vim 7.4x ready for beta testing

[raf]

Bram Moolenaar wrote:

> Hello Vim users,
> 
> Announcing:  Vim (Vi IMproved) version 7.4x BETA
> 
> This is the first BETA release for Vim 8
> 
> Please check that the distribution is OK.  I haven't done one for a long
> time.  Report anything that isn't right.  That includes a crash but also
> a typo in the documentation or a missing file.

Happy to report that a Huge version with X11-Motif GUI on my crusty
old macosx-10.6.8 system compiles and tests fine from the tarball.

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] :cexpr and :cgetexpr not included in QuickFixCmdPre/QuickFixCmdPost autocmd triggers (#1021)

[Yegappan Lakshmanan]

Hi,

On Tue, Aug 30, 2016 at 6:25 AM, Mathias Stearn
 wrote:
> They are not used for commands like cfile, cbuffer and cexpr etc.
>
> Actually, cfile is one of the commands that triggers QuickFixCmdPre/Post:
> https://github.com/vim/vim/blob/bc8801c/runtime/doc/autocmd.txt#L780-L801
>

The attached patch fixes this problem. Now the pre/post autocmds are invoked
for the cexpr/cgetexpr/caddexpr/cbuffer/cgetbuffer/caddbuffer commands also.

- Yegappan

>
> Is there a better way to achieve the goal of always opening the quickfix
> window whenever I run a command that populates it?
>

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/runtime/doc/autocmd.txt b/runtime/doc/autocmd.txt
index e3ba3d7..e5dc741 100644
--- a/runtime/doc/autocmd.txt
+++ b/runtime/doc/autocmd.txt
@@ -784,7 +784,9 @@ QuickFixCmdPre  Before a quickfix 
command is run (|:make|,
|:vimgrepadd|, |:lvimgrepadd|, |:cscope|,
|:cfile|, |:cgetfile|, |:caddfile|, |:lfile|,
|:lgetfile|, |:laddfile|, |:helpgrep|,
-   |:lhelpgrep|).
+   |:lhelpgrep|, |:cexpr|, |:cgetexpr|,
+   |:caddexpr|, |:cbuffer|, |:cgetbuffer|,
+   |:caddbuffer|).
The pattern is matched against the command
being run.  When |:grep| is used but 'grepprg'
is set to "internal" it still matches "grep".
diff --git a/src/quickfix.c b/src/quickfix.c
index d022061..2f5256b 100644
--- a/src/quickfix.c
+++ b/src/quickfix.c
@@ -4845,6 +4845,9 @@ ex_cbuffer(exarg_T *eap)
 {
 buf_T  *buf = NULL;
 qf_info_T  *qi = _info;
+#ifdef FEAT_AUTOCMD
+char_u *au_name = NULL;
+#endif
 
 if (eap->cmdidx == CMD_lbuffer || eap->cmdidx == CMD_lgetbuffer
|| eap->cmdidx == CMD_laddbuffer)
@@ -4854,6 +4857,28 @@ ex_cbuffer(exarg_T *eap)
return;
 }
 
+#ifdef FEAT_AUTOCMD
+switch (eap->cmdidx)
+{
+   case CMD_cbuffer:   au_name = (char_u *)"cbuffer"; break;
+   case CMD_cgetbuffer:au_name = (char_u *)"cgetbuffer"; break;
+   case CMD_caddbuffer:au_name = (char_u *)"caddbuffer"; break;
+   case CMD_lbuffer:   au_name = (char_u *)"lbuffer"; break;
+   case CMD_lgetbuffer:au_name = (char_u *)"lgetbuffer"; break;
+   case CMD_laddbuffer:au_name = (char_u *)"laddbuffer"; break;
+   default: break;
+}
+if (au_name != NULL)
+{
+   apply_autocmds(EVENT_QUICKFIXCMDPRE, au_name,
+  curbuf->b_fname, TRUE, curbuf);
+# ifdef FEAT_EVAL
+   if (did_throw || force_abort)
+   return;
+# endif
+}
+#endif
+
 if (*eap->arg == NUL)
buf = curbuf;
 else if (*skipwhite(skipdigits(eap->arg)) == NUL)
@@ -4887,10 +4912,16 @@ ex_cbuffer(exarg_T *eap)
(eap->cmdidx != CMD_caddbuffer
 && eap->cmdidx != CMD_laddbuffer),
   eap->line1, eap->line2,
-  qf_title) > 0
-   && (eap->cmdidx == CMD_cbuffer
-   || eap->cmdidx == CMD_lbuffer))
-   qf_jump(qi, 0, 0, eap->forceit);  /* display first error */
+  qf_title) > 0)
+   {
+#ifdef FEAT_AUTOCMD
+   if (au_name != NULL)
+   apply_autocmds(EVENT_QUICKFIXCMDPOST, au_name,
+   curbuf->b_fname, TRUE, curbuf);
+#endif
+   if (eap->cmdidx == CMD_cbuffer || eap->cmdidx == CMD_lbuffer)
+   qf_jump(qi, 0, 0, eap->forceit);  /* display first error */
+   }
}
 }
 }
@@ -4905,6 +4936,9 @@ ex_cexpr(exarg_T *eap)
 {
 typval_T   *tv;
 qf_info_T  *qi = _info;
+#ifdef FEAT_AUTOCMD
+char_u *au_name = NULL;
+#endif
 
 if (eap->cmdidx == CMD_lexpr || eap->cmdidx == CMD_lgetexpr
|| eap->cmdidx == CMD_laddexpr)
@@ -4914,6 +4948,28 @@ ex_cexpr(exarg_T *eap)
return;
 }
 
+#ifdef FEAT_AUTOCMD
+switch (eap->cmdidx)
+{
+   case CMD_cexpr: au_name = (char_u *)"cexpr"; break;
+   case CMD_cgetexpr:  au_name = (char_u *)"cgetexpr"; break;
+   case CMD_caddexpr:  au_name = (char_u *)"caddexpr"; break;
+   case CMD_lexpr: au_name = 

Re: has('channel')

[Christian J. Robinson]

On Tue, 30 Aug 2016, David Fishburn wrote:

Just reading through channel.txt and noticed there is not reference 
to how to check if Vim supports channels or not for jobs.


It's referenced in ":help +feature-list".

- Christian

--
Christian J. Robinson 
If it's not in the computer, it doesn't exist.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

has('channel')

[David Fishburn]

Just reading through channel.txt and noticed there is not reference to how
to check if Vim supports channels or not for jobs.

Perhaps the samples in there should have:

if has('channel')
...
endif

David

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[patch] add tests for :undolist and the normal U command

[Dominique Pellé]

Hi

Attached patch adds tests for:
- the  :undolist command
- the normal U command

According to https://coveralls.io/github/vim/vim?branch=master
these were not yet covered by tests.

Regards
Dominique

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/testdir/test_undo.vim b/src/testdir/test_undo.vim
index e521e35..fb1cdc8 100644
--- a/src/testdir/test_undo.vim
+++ b/src/testdir/test_undo.vim
@@ -129,6 +129,39 @@ func Test_undo_del_chars()
   close!
 endfunc
 
+func Test_undolist()
+  new
+  set ul=100
+
+  let a=execute('undolist')
+  call assert_equal("\nNothing to undo", a)
+
+  " 1 leaf (2 changes).
+  call feedkeys('achange1', 'xt')
+  call feedkeys('achange2', 'xt')
+  let a=execute('undolist')
+  call assert_match("^\nnumber changes  when  *saved\n *2  *2 .*$", a)
+
+  " 2 leaves.
+  call feedkeys('u', 'xt')
+  call feedkeys('achange3\', 'xt')
+  let a=execute('undolist')
+  call assert_match("^\nnumber changes  when  *saved\n *2  *2  *.*\n *3  *2 .*$", a)
+  close!
+endfunc
+
+func Test_U_command()
+  new
+  set ul=100
+  call feedkeys("achange1\", 'xt')
+  call feedkeys("achange2\", 'xt')
+  norm! U
+  call assert_equal('', getline(1))
+  norm! U
+  call assert_equal('change1change2', getline(1))
+  close!
+endfunc
+
 func Test_undojoin()
   new
   call feedkeys("Go\", 'xt')

Re: syntax clear -- should it be removed from syntax files?

[Bram Moolenaar]

Charles Campbell wrote:

> In nosing around the help, I see for :help filetypedetect-changed the
> following:
> 
> The distributed syntax files no longer contain "syntax clear".  That
> makes it
> possible to include one in the other without tricks.  The syntax is now
> cleared when the 'syntax' option is set (by an autocommand added from
> synload.vim).  This makes the syntax cleared when the value of 'syntax' does
> not correspond to a syntax file.  Previously the existing highlighting was
> kept.
> 
> However:
> 
> fgrep "syn clear" *.vim | wc  shows 56 files with this command, and
> fgrep "syntax clear" *.vim | wc shows 357 files with this command.
> 
> Should all the syn(tax) clears be removed?  Or am I reading the above
> paragraph incorrectly?

These should all be inside an if:

if version < 600
  syntax clear
elseif exists("b:current_syntax")
  finish
endif

Since version 6 is now very old, we could change all of them to:

if exists("b:current_syntax")
  finish
endif

Perhaps I should just do that now, so that it's consistent.

-- 
hundred-and-one symptoms of being an internet addict:
112. You are amazed that anyone uses a phone without a modem on it...let
 alone hear actual voices.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [patch] mention skipped tests for new_style tests

[Christian Brabandt]

On Di, 30 Aug 2016, Christian Brabandt wrote:

> Hm, let's try the second approach for the test_popup.vim
> 
> Will submit a patch soon.

How about the attached patch?

Best,
Christian
-- 
Jeder Weg führt zum Glück. Die Frage ist, wieviel Trauer
auf dem Weg liegt.
-- Benjamin Stramke

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/testdir/Makefile b/src/testdir/Makefile
index 2153039..08f11cd 100644
--- a/src/testdir/Makefile
+++ b/src/testdir/Makefile
@@ -121,7 +121,7 @@ nolog:
 RUN_VIMTEST = VIMRUNTIME=$(SCRIPTSOURCE); export VIMRUNTIME; $(VALGRIND) $(VIMPROG) -f $(GUI_FLAG) -u unix.vim $(NO_PLUGIN)
 
 newtests: newtestssilent
-	@/bin/sh -c "if test -f messages && grep -q 'FAILED' messages; then cat messages && cat test.log; fi"
+	@/bin/sh -c "if test -f messages && grep -q 'SKIPPED\|FAILED' messages; then cat messages && if test -f test.log; then cat test.log; fi ; fi"
 
 newtestssilent: $(NEW_TESTS)
 
diff --git a/src/testdir/runtest.vim b/src/testdir/runtest.vim
index 2660d93..2b23aed 100644
--- a/src/testdir/runtest.vim
+++ b/src/testdir/runtest.vim
@@ -86,6 +86,10 @@ function GetAllocId(name)
   return lnum - top - 1
 endfunc
 
+func ListSort(i1, i2)
+  return a:i1 =~# '^SKIPPED' ? 1 : 0
+endfunc
+
 function RunTheTest(test)
   echo 'Executing ' . a:test
   if exists("*SetUp")
@@ -96,6 +100,9 @@ function RunTheTest(test)
   let s:done += 1
   try
 exe 'call ' . a:test
+  catch /^\cskip/
+"call add(s:messages, 'Skipping test: ' . a:test . ': ' . matchstr(v:exception, 'skipp.*\>\s*\zs'))
+call add(s:messages, 'SKIPPED ' . a:test . ': ' . join(split(v:exception, '\s\+')[1:], ' '))
   catch
 call add(v:errors, 'Caught exception in ' . a:test . ': ' . v:exception . ' @ ' . v:throwpoint)
   endtry
@@ -201,6 +208,7 @@ if s:fail > 0
 endif
 
 " Append messages to "messages"
+call sort(s:messages, "ListSort")
 split messages
 call append(line('$'), '')
 call append(line('$'), 'From ' . g:testname . ':')
diff --git a/src/testdir/test_popup.vim b/src/testdir/test_popup.vim
index 34a2251..dd94933 100644
--- a/src/testdir/test_popup.vim
+++ b/src/testdir/test_popup.vim
@@ -16,6 +16,21 @@ func! ListMonths()
   return ''
 endfunc
 
+func! Test_popup_complete2()
+  " Insert match immediately, if there is only one match
+  "   Should select a character from the line below
+  " TODO: test disabled because the code change has been reverted.
+  throw "Skipped: Bug with  and popupmenu not fixed yet"
+  new
+  inoremap  =ListMonths()
+  call append(1, ["December2015"])
+  :1
+  call feedkeys("aD\\\", 'tx')
+  call assert_equal(["December2015", "", "December2015"], getline(1,3))
+  %d
+  bw!
+endfu
+
 func! Test_popup_complete()
   new
   inoremap  =ListMonths()
@@ -168,15 +183,6 @@ func! Test_popup_complete()
   call assert_equal(["December2015", "December2015", ""], getline(1,3))
   %d
 
-  " Insert match immediately, if there is only one match
-  "   Should select a character from the line below
-  " TODO: test disabled because the code change has been reverted.
-  " call append(1, ["December2015"])
-  " :1
-  " call feedkeys("aD\\\", 'tx')
-  " call assert_equal(["December2015", "", "December2015"], getline(1,3))
-  " %d
-
   " use menuone for 'completeopt'
   " Since for the first  the menu is still shown, will only select
   " three letters from the line above

syntax clear -- should it be removed from syntax files?

[Charles E Campbell]

Hello:

In nosing around the help, I see for :help filetypedetect-changed the
following:

The distributed syntax files no longer contain "syntax clear".  That
makes it
possible to include one in the other without tricks.  The syntax is now
cleared when the 'syntax' option is set (by an autocommand added from
synload.vim).  This makes the syntax cleared when the value of 'syntax' does
not correspond to a syntax file.  Previously the existing highlighting was
kept.

However:

fgrep "syn clear" *.vim | wc  shows 56 files with this command, and
fgrep "syntax clear" *.vim | wc shows 357 files with this command.

Should all the syn(tax) clears be removed?  Or am I reading the above
paragraph incorrectly?

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: make report fails in testdir at v7.4.2290

[Elimar Riesebieter]

* Bram Moolenaar  [2016-08-29 21:55 +0200]:

> 
> Elimar Riesebieter wrote:
> 
> > $ make report
> > 
> > Test results:
> > 
> > 
> > >From test_alot.vim:
> > Found errors in Test_tabpage_with_tab_modifier():
> > function 
> > RunTheTest[9]..Test_tabpage_with_tab_modifier[13]..40_check_tab line 
> > 4: Expected 'help' but got 'text'
> > function 
> > RunTheTest[9]..Test_tabpage_with_tab_modifier[14]..40_check_tab line 
> > 4: Expected 'help' but got 'text'
> > function 
> > RunTheTest[9]..Test_tabpage_with_tab_modifier[15]..40_check_tab line 
> > 4: Expected 'help' but got 'text'
> > function 
> > RunTheTest[9]..Test_tabpage_with_tab_modifier[16]..40_check_tab line 
> > 4: Expected 'help' but got 'text'
> > function 
> > RunTheTest[9]..Test_tabpage_with_tab_modifier[17]..40_check_tab line 
> > 4: Expected 'help' but got 'text'
> > function 
> > RunTheTest[9]..Test_tabpage_with_tab_modifier[18]..40_check_tab line 
> > 4: Expected 'help' but got 'text'
> > function 
> > RunTheTest[9]..Test_tabpage_with_tab_modifier[19]..40_check_tab line 
> > 4: Expected 'help' but got 'text'
> > function 
> > RunTheTest[9]..Test_tabpage_with_tab_modifier[20]..40_check_tab line 
> > 4: Expected 'help' but got 'text'
> > function 
> > RunTheTest[9]..Test_tabpage_with_tab_modifier[21]..40_check_tab line 
> > 4: Expected 'help' but got 'text'
> > function 
> > RunTheTest[9]..Test_tabpage_with_tab_modifier[22]..40_check_tab line 
> > 4: Expected 'help' but got 'text'
> > TEST FAILURE
> > Makefile:41: recipe for target 'report' failed
> > make: *** [report] Error 1
> 
> Works for me and I assume most others.  What is special about your
> setup?  How did you get the sources?

Fetched sources via git, building in a $SHADOWDIR.

Elimar
-- 
  On the keyboard of life you have always
  to keep a finger at the escape key;-)

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Diff should indicate if no differences detected

[JohnBeckett]

On Tuesday, August 30, 2016 at 5:56:01 AM UTC+10, Bram Moolenaar wrote:
>> gvim -N -u NONE
>>
>> :let lines = range(1, 999)
>> :call writefile(lines, 'old.tmp')
>> :call writefile(['inserted'] + lines, 'new.tmp')
>> :e new.tmp
>> :vert diffs old.tmp
>>
>> One way to execute the commands is to copy the lines to the
>> clipboard. In Vim, type @+
>>
>> Result: See two windows side-by-side. They appear to be
>> identical, with each window showing:
>>
>> 1
>> 2
>> 3
>> 4
>> 5
>> 6
>> +--993 lines: 7--
>>
>> The cursor is on "1" at the top of the left-hand window.
>> Pressing [c does nothing other than ring the bell. The only way
>> I know to see that the two files are different is to switch to
>> the right-hand window and scroll up ([c works).
>>
>> I'm never confident any more that a diff is showing everything.
>
> For me, when the files are identical I would not see any lines
> of text, only the closed fold.  Perhaps your setting is to
> always open the fold under the cursor?
>
> That filler lines may hide above the window is hard to avoid.
> We can't disallow scrolling the window into that position.
> Scrolling one line down to reveal one filler line is not so
> easy in general, would only work in some situations.  E.g.
> when the line wraps in the other window it may completely fill
> the window and the cursor line can't be displayed.

Thanks, you are right and that works for me. The fact that I can
see some lines open (after the recent patch) means there is a
difference.

John

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: bug with folding

[Christian Brabandt]

Am 2016-08-29 22:13, schrieb Christian Brabandt:

Hi Bram!

On Mo, 29 Aug 2016, Bram Moolenaar wrote:



Christian Brabandt wrote:

> I am currently writing some tests for normal.c, to increase the coverage.
>
> Unfortunately, I noteiced some bugs with folding: Here is one issue:
>
> ~$ vim -u NONE -N
> call setline(1, range(1,10)
> :3
> norm! 2zF
> :2
> norm! 5zF
> :set nofoldenable
> :3
> norm! zc  -> folds line 2 - 8, I would have expected to only close the inner 
fold 3-4, but perhaps that is expected, but see below:
> set nofoldenable
> norm! Vzc -> correctly folds 3-4
> :set nofoldenable
> norm! zc -> folds lines 3-4?


Actually, I can't seem to verify this bug on a recent Vim. It seems to 
always fold the longer range.

Can someone confirm this behaviour?

Best,
Christian

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [patch] mention skipped tests for new_style tests

[Christian Brabandt]

Am 2016-08-29 22:30, schrieb Bram Moolenaar:

Christian Brabandt wrote:


Hi,
while working on some more tests, I noticed some bugs. I will report
them separately, whenever I have a test, that is reproducible
stand-alone, but until then, I like to disable some tests (and don't
forget about them).

However, it would be nice, if the logfile could mention, if a test has
been skipped, and which one.

Therefore here is a patch, that adds this ability. See the commit
message for an detailed explanation.


Hmm, this looks a bit complicated.  I can think of two alternatives:

1. Name the test Test_skip_my_test()
   Then the runtest script can report
Executing Test_normal11_showcmd()
SKIPPING Test_skip_my_test()

2. Throw the reason:
func Test_my_stuff()
  throw 'skipped: need to fix the bug first'
  ...
   Then runtest would report
Executing Test_my_stuff()
SKIPPED

Although completely commenting out the function also works.


That also means, it only works with complete functions, not part of 
functions?


Hm, let's try the second approach for the test_popup.vim

Will submit a patch soon.

Best,
Christian

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.