Re: Stuff in testdir
Bill McCarthy wrote: There is a `testdir' located in $VIMRUNTIME/src. There doesn't appear to be any documentation of this, but there is a set of tests that run from within various make files. I'm running in Windows.using Mingw. The makefile for windows is apparently Make_dos.mak. The top of that file mentioned that one needs typical unix utilities. However, if you have the unix utilities, you very likely have at least sh.exe and probably zsh.exe (the Bourne and Z-Shell). Can't you use Makefile, as used for Unix? However, I thought that MingW was supposed to just supply the compiler, not all the Unix tools like Cygwin. So Make_dos.mak would be more appropriate. Thanks for your speedy reply. No, Makefile does not work: make rm -f test.log make: *** No rule to make target `../vim', needed by `test1.out'. Stop. You are correct that Mingw is not a complete package. One needs to download the various unix utilities separately. But one usually gets sh.exe also - I also got zsh.exe in one of my downloads of unix utilities. [They don't all play well with Windows, so one needs to test quite a bit.] Isn't it possible to make the tests work without the extra downloads? Using a testdir/Make_ming.mak, which mostly uses the DOS way of doing things should work, right? Adding a dependency on installing various other tools is not nice. The GNU make command will use zsh (or sh if zsh is not present). Only if neither of these are in your path is CMD used - and you CAN use Make_dos.mak. I've created Make_dos_sh.mak which should work with either sh.exe or zsh.exe - this is attached. When I ran it with `make -f Make_dos_sh.mak', test54 failed with the following: cp test54.ok test.ok ../vim -u dos.vim -U NONE --noplugin -s dotest.in test54.in diff test.out test54.ok diff: test.out: No such file or directory make: *** [test54.out] Error 2 Am I the first one to ever run these tests in Windows? This test uses Unix commands. They can probably be avoided, since the buffer-local autocommands don't require a shell command. Yes, the CMD command `rm -f' is a problem. I've removed this bad test and added a comment to the top of the new file (see attached). I've put a remark on the todo list to change test54. However, the todo list is very, very long... When I run `make Make_dos_sh.mak clean' it cleans things up. Are there other targets I should use for a full test or is that accomplished with the make file? One little problem. The unix utility command `rm -f X*' produces an error message with there are no X* files. What is the way around that? I think that's normal. OK. With test54 removed, I've run several tests and they each produced an `ALL DONE'. Apparently that means everything worked? Or that nothing was tested :-). Here are the tests I ran: make -f Make_dos_sh.mak nongui make -f Make_dos_sh.mak small make -f Make_dos_sh.mak gui make -f Make_dos_sh.mak win32 The second test isn't much of a test :-) -- Never go to the toilet in a paperless office. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Patch 7.2.016
Patch 7.2.016
Problem:The pattern being completed may be in freed memory when the
command line is being reallocated. (Dominique Pelle)
Solution: Keep a pointer to the expand_T in the command line structure.
Don't use S-Tab as CTRL-P when there are no results. Clear the
completion when using a command line from the history.
Files: src/ex_getln.c
*** ../vim-7.2.015/src/ex_getln.c Fri Aug 8 12:58:59 2008
--- src/ex_getln.c Wed Sep 10 22:43:41 2008
***
*** 31,36
--- 31,38
int cmdattr;/* attributes for prompt */
int overstrike; /* Typing mode on the command line.
Shared by
getcmdline() and put_on_cmdline(). */
+ expand_T *xpc; /* struct being used for expansion, xp_pattern
+ may point into cmdbuff */
int xp_context; /* type of expansion */
# ifdef FEAT_EVAL
char_u*xp_arg;/* user-defined expansion arg */
***
*** 38,44
# endif
};
! static struct cmdline_info ccline;/* current cmdline_info */
static intcmd_showtail; /* Only show path tail in lists ? */
--- 40,50
# endif
};
! /* The current cmdline_info. It is initialized in getcmdline() and after that
! * used by other functions. When invoking getcmdline() recursively it needs
! * to be saved with save_cmdline() and restored with restore_cmdline().
! * TODO: make it local to getcmdline() and pass it around. */
! static struct cmdline_info ccline;
static intcmd_showtail; /* Only show path tail in lists ? */
***
*** 238,243
--- 244,250
}
ExpandInit(xpc);
+ ccline.xpc = xpc;
#ifdef FEAT_RIGHTLEFT
if (curwin-w_p_rl *curwin-w_p_rlc == 's'
***
*** 408,416
#endif
/*
!* S-Tab works like CTRL-P (unless 'wc' is S-Tab).
*/
! if (c != p_wc c == K_S_TAB xpc.xp_numfiles != -1)
c = Ctrl_P;
#ifdef FEAT_WILDMENU
--- 415,424
#endif
/*
!* When there are matching completions to select S-Tab works like
!* CTRL-P (unless 'wc' is S-Tab).
*/
! if (c != p_wc c == K_S_TAB xpc.xp_numfiles 0)
c = Ctrl_P;
#ifdef FEAT_WILDMENU
***
*** 1513,1518
--- 1521,1527
int old_firstc;
vim_free(ccline.cmdbuff);
+ xpc.xp_context = EXPAND_NOTHING;
if (hiscnt == hislen)
p = lookfor;/* back to the old one */
else
***
*** 1839,1844
--- 1848,1854
#endif
ExpandCleanup(xpc);
+ ccline.xpc = NULL;
#ifdef FEAT_SEARCH_EXTRA
if (did_incsearch)
***
*** 2508,2513
--- 2518,2537
}
mch_memmove(ccline.cmdbuff, p, (size_t)ccline.cmdlen + 1);
vim_free(p);
+
+ if (ccline.xpc != NULL
+ccline.xpc-xp_pattern != NULL
+ccline.xpc-xp_context != EXPAND_NOTHING
+ccline.xpc-xp_context != EXPAND_UNSUCCESSFUL)
+ {
+ int i = ccline.xpc-xp_pattern - p;
+
+ /* If xp_pattern points inside the old cmdbuff it needs to be adjusted
+* to point into the newly allocated memory. */
+ if (i = 0 i = ccline.cmdlen)
+ ccline.xpc-xp_pattern = ccline.cmdbuff + i;
+ }
+
return OK;
}
***
*** 2875,2880
--- 2899,2905
prev_ccline = ccline;
ccline.cmdbuff = NULL;
ccline.cmdprompt = NULL;
+ ccline.xpc = NULL;
}
/*
***
*** 3582,3587
--- 3607,3613
ExpandInit(xp)
expand_T *xp;
{
+ xp-xp_pattern = NULL;
xp-xp_backslash = XP_BS_NONE;
#ifndef BACKSLASH_IN_FILENAME
xp-xp_shell = FALSE;
*** ../vim-7.2.015/src/version.cWed Sep 10 18:25:18 2008
--- src/version.c Sun Sep 14 14:38:47 2008
***
*** 678,679
--- 678,681
{ /* Add new patch number below this line */
+ /**/
+ 16,
/**/
--
hundred-and-one symptoms of being an internet addict:
53. To find out what time it is, you send yourself an e-mail and check the
Date: field.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Patch 7.2.017
Patch 7.2.017
Problem:strlen() used on text that may not end in a NUL. (Dominique Pelle)
Pasting a very big selection doesn't work.
Solution: Use the length passed to the XtSelectionCallbackProc() function.
After getting the SelectionNotify event continue dispatching
events until the callback is actually called. Also dispatch the
PropertyNotify event.
Files: src/ui.c
*** ../vim-7.2.016/src/ui.c Sun Sep 7 21:47:51 2008
--- src/ui.cSun Sep 14 15:52:19 2008
***
*** 2020,2026
if (value == NULL || *length == 0)
{
! clip_free_selection(cbd); /* ??? [what's the query?] */
*(int *)success = FALSE;
return;
}
--- 2020,2026
if (value == NULL || *length == 0)
{
! clip_free_selection(cbd); /* nothing received, clear register */
*(int *)success = FALSE;
return;
}
***
*** 2076,2082
text_prop.value = (unsigned char *)value;
text_prop.encoding = *type;
text_prop.format = *format;
! text_prop.nitems = STRLEN(value);
status = XmbTextPropertyToTextList(X_DISPLAY, text_prop,
text_list, n_text);
if (status != Success || n_text 1)
--- 2076,2082
text_prop.value = (unsigned char *)value;
text_prop.encoding = *type;
text_prop.format = *format;
! text_prop.nitems = len;
status = XmbTextPropertyToTextList(X_DISPLAY, text_prop,
text_list, n_text);
if (status != Success || n_text 1)
***
*** 2131,2137
case 3: type = text_atom; break;
default: type = XA_STRING;
}
! success = FALSE;
XtGetSelectionValue(myShell, cbd-sel_atom, type,
clip_x11_request_selection_cb, (XtPointer)success, CurrentTime);
--- 2131,2137
case 3: type = text_atom; break;
default: type = XA_STRING;
}
! success = MAYBE;
XtGetSelectionValue(myShell, cbd-sel_atom, type,
clip_x11_request_selection_cb, (XtPointer)success, CurrentTime);
***
*** 2145,2169
* paste! Don't worry, we will catch up with any other events later.
*/
start_time = time(NULL);
! for (;;)
{
! if (XCheckTypedEvent(dpy, SelectionNotify, event))
{
! /* this is where clip_x11_request_selection_cb() is actually
!* called */
XtDispatchEvent(event);
! break;
}
- if (XCheckTypedEvent(dpy, SelectionRequest, event))
- /* We may get a SelectionRequest here and if we don't handle
-* it we hang. KDE klipper does this, for example. */
- XtDispatchEvent(event);
/* Time out after 2 to 3 seconds to avoid that we hang when the
* other process doesn't respond. Note that the SelectionNotify
* event may still come later when the selection owner comes back
!* to life and the text gets inserted unexpectedly (by xterm).
!* Don't know how to avoid that :-(. */
if (time(NULL) start_time + 2)
{
timed_out = TRUE;
--- 2145,2171
* paste! Don't worry, we will catch up with any other events later.
*/
start_time = time(NULL);
! while (success == MAYBE)
{
! if (XCheckTypedEvent(dpy, SelectionNotify, event)
! || XCheckTypedEvent(dpy, SelectionRequest, event)
! || XCheckTypedEvent(dpy, PropertyNotify, event))
{
! /* This is where clip_x11_request_selection_cb() should be
!* called. It may actually happen a bit later, so we loop
!* until success changes.
!* We may get a SelectionRequest here and if we don't handle
!* it we hang. KDE klipper does this, for example.
!* We need to handle a PropertyNotify for large selections. */
XtDispatchEvent(event);
! continue;
}
/* Time out after 2 to 3 seconds to avoid that we hang when the
* other process doesn't respond. Note that the SelectionNotify
* event may still come later when the selection owner comes back
!* to life and the text gets inserted unexpectedly. Don't know
!* why that happens or how to avoid that :-(. */
if (time(NULL) start_time + 2)
{
timed_out = TRUE;
***
*** 2177,2183
ui_delay(1L, TRUE);
}
! if (success)
return;
/* don't do a retry with another type after timing out, otherwise we
---
Re: Stuff in testdir
On Sun 14-Sep-08 6:21am -0600, Bram Moolenaar wrote: Bill McCarthy wrote: There is a `testdir' located in $VIMRUNTIME/src. There doesn't appear to be any documentation of this, but there is a set of tests that run from within various make files. I'm running in Windows.using Mingw. The makefile for windows is apparently Make_dos.mak. The top of that file mentioned that one needs typical unix utilities. However, if you have the unix utilities, you very likely have at least sh.exe and probably zsh.exe (the Bourne and Z-Shell). Can't you use Makefile, as used for Unix? However, I thought that MingW was supposed to just supply the compiler, not all the Unix tools like Cygwin. So Make_dos.mak would be more appropriate. Thanks for your speedy reply. No, Makefile does not work: make rm -f test.log make: *** No rule to make target `../vim', needed by `test1.out'. Stop. You are correct that Mingw is not a complete package. One needs to download the various unix utilities separately. But one usually gets sh.exe also - I also got zsh.exe in one of my downloads of unix utilities. [They don't all play well with Windows, so one needs to test quite a bit.] Isn't it possible to make the tests work without the extra downloads? Using a testdir/Make_ming.mak, which mostly uses the DOS way of doing things should work, right? Adding a dependency on installing various other tools is not nice. Yes, I've created Make_ming.mak which works whether running from CMD, sh or zsh. I've borrowed from your Make_ming.mak in src for compiling. See attached. Test has been tested under my environment and under CMD after removing both sh.exe and zsh.exe from my path. The GNU make command will use zsh (or sh if zsh is not present). Only if neither of these are in your path is CMD used - and you CAN use Make_dos.mak. I've created Make_dos_sh.mak which should work with either sh.exe or zsh.exe - this is attached. When I ran it with `make -f Make_dos_sh.mak', test54 failed with the following: cp test54.ok test.ok ../vim -u dos.vim -U NONE --noplugin -s dotest.in test54.in diff test.out test54.ok diff: test.out: No such file or directory make: *** [test54.out] Error 2 Am I the first one to ever run these tests in Windows? This test uses Unix commands. They can probably be avoided, since the buffer-local autocommands don't require a shell command. Yes, the CMD command `rm -f' is a problem. I've removed this bad test and added a comment to the top of the new file (see attached). I've put a remark on the todo list to change test54. However, the todo list is very, very long... I misspoke. The `rm -f' is NOT a problem - the user should have that utility. There is another problem with test54. When I run `make Make_dos_sh.mak clean' it cleans things up. Are there other targets I should use for a full test or is that accomplished with the make file? One little problem. The unix utility command `rm -f X*' produces an error message with there are no X* files. What is the way around that? I think that's normal. OK. With test54 removed, I've run several tests and they each produced an `ALL DONE'. Apparently that means everything worked? Or that nothing was tested :-). Here are the tests I ran: make -f Make_dos_sh.mak nongui make -f Make_dos_sh.mak small make -f Make_dos_sh.mak gui make -f Make_dos_sh.mak win32 The second test isn't much of a test :-) Why not have a test that tests all of them: vimall:TABfixff $(SCRIPTS16) $(SCRIPTS) $(SCRIPTS_GUI) $(SCRIPTS32) Otherwise we appear to redundantly test. This should be the first (default) test. I've added it to Make_ming.mak for testdir. -- Best regards, Bill --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- # # Makefile to run tests for Vim, on Dos-like machines # with sh.exe or zsh.exe in the path or not. # # Note that test54 has been removed until it is fixed. # # Requires a set of Unix tools: echo, diff, etc. ifneq (sh.exe, $(SHELL)) DEL = rm -f MV = mv CP = cp DIRSLASH = / else DEL = del MV = rename CP = copy DIRSLASH = \\ endif VIMPROG = ..$(DIRSLASH)vim # Omitted: # test2 \\tmp doesn't work. # test10'errorformat' is different # test12can't unlink a swap file # test25uses symbolic link # test27can't edit file with * in file name # test3116 bit version runs out of memory... SCRIPTS16 = test1.out test19.out test20.out test22.out \ test23.out test24.out test28.out test29.out \ test35.out test36.out test43.out \ test44.out test45.out test46.out test47.out \ test48.out test51.out test53.out\ test55.out
Re: ANNC: Relative Numbering plugin
On Mon 18 Aug 2008 at 16:15:10 -0400, Charles Campbell wrote: Hello! I've issued a new plugin on my website: http://mysite.verizon.net/astronaut/vim/index.html#RLTVNMBR . It uses The link you have there, http://groups.google.com/group/vim_dev/attach/10fa0944a8b643b4/vim-7.2-relativenumber-02.patch?part=2 , redirects (now, maybe not before?) to http://vim_dev.googlegroups.com/attach/10fa0944a8b643b4/vim-7.2-relativenumber-02.patch?part=2 which Firefox complains that it cannot find (Address Not Found Firefox can't find the server at vim_dev.googlegroups.com.). That is probably because host names with an underscore (vim_dev.googlegroups.com) are not allowed. Doesn't anyone else notice that? Chip Campbell -Olaf. -- ___ Olaf 'Rhialto' Seibert -- You author it, and I'll reader it. \X/ rhialto/at/xs4all.nl-- Cetero censeo authored delendum esse. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: ANNC: Relative Numbering plugin
On 14/09/08 20:57, Rhialto wrote: On Mon 18 Aug 2008 at 16:15:10 -0400, Charles Campbell wrote: Hello! I've issued a new plugin on my website: http://mysite.verizon.net/astronaut/vim/index.html#RLTVNMBR . It uses The link you have there, http://groups.google.com/group/vim_dev/attach/10fa0944a8b643b4/vim-7.2-relativenumber-02.patch?part=2 , redirects (now, maybe not before?) to http://vim_dev.googlegroups.com/attach/10fa0944a8b643b4/vim-7.2-relativenumber-02.patch?part=2 which Firefox complains that it cannot find (Address Not Found Firefox can't find the server at vim_dev.googlegroups.com.). That is probably because host names with an underscore (vim_dev.googlegroups.com) are not allowed. Doesn't anyone else notice that? Chip Campbell -Olaf. What do you mean, they aren't allowed? Not only do all the Vim Google Groups include an underscore in their names, when I click that link (in SeaMonkey on openSUSE Linux 11.0) I get a page saying Found. Please click the following link to continue: with a much longer link. Best regards, Tony. -- I could dance till the cows come home. On second thought, I'd rather dance with the cows till you come home. -- Groucho Marx --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Patch 7.2.018
Patch 7.2.018
Problem:Memory leak when substitute is aborted.
Solution: Free the buffer allocated for the new text. (Dominique Pelle)
Files: src/ex_cmds.c
*** ../vim-7.2.017/src/ex_cmds.cWed Aug 6 15:03:07 2008
--- src/ex_cmds.c Sun Sep 14 13:45:03 2008
***
*** 5059,5064
--- 5059,5065
if (did_sub)
++sub_nlines;
+ vim_free(new_start);/* for when substitute was cancelled */
vim_free(sub_firstline);/* free the copy of the original line */
sub_firstline = NULL;
}
*** ../vim-7.2.017/src/version.cSun Sep 14 15:57:54 2008
--- src/version.c Sun Sep 14 21:38:25 2008
***
*** 678,679
--- 678,681
{ /* Add new patch number below this line */
+ /**/
+ 18,
/**/
--
hundred-and-one symptoms of being an internet addict:
55. You ask your doctor to implant a gig in your brain.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Stuff in testdir
Bill McCarthy wrote: You are correct that Mingw is not a complete package. One needs to download the various unix utilities separately. But one usually gets sh.exe also - I also got zsh.exe in one of my downloads of unix utilities. [They don't all play well with Windows, so one needs to test quite a bit.] Isn't it possible to make the tests work without the extra downloads? Using a testdir/Make_ming.mak, which mostly uses the DOS way of doing things should work, right? Adding a dependency on installing various other tools is not nice. Yes, I've created Make_ming.mak which works whether running from CMD, sh or zsh. I've borrowed from your Make_ming.mak in src for compiling. See attached. Test has been tested under my environment and under CMD after removing both sh.exe and zsh.exe from my path. Great. I'll include this. Please send a new version when you make improvements. The GNU make command will use zsh (or sh if zsh is not present). Only if neither of these are in your path is CMD used - and you CAN use Make_dos.mak. I've created Make_dos_sh.mak which should work with either sh.exe or zsh.exe - this is attached. When I ran it with `make -f Make_dos_sh.mak', test54 failed with the following: cp test54.ok test.ok ../vim -u dos.vim -U NONE --noplugin -s dotest.in test54.in diff test.out test54.ok diff: test.out: No such file or directory make: *** [test54.out] Error 2 Am I the first one to ever run these tests in Windows? This test uses Unix commands. They can probably be avoided, since the buffer-local autocommands don't require a shell command. Yes, the CMD command `rm -f' is a problem. I've removed this bad test and added a comment to the top of the new file (see attached). I've put a remark on the todo list to change test54. However, the todo list is very, very long... I misspoke. The `rm -f' is NOT a problem - the user should have that utility. There is another problem with test54. When I run `make Make_dos_sh.mak clean' it cleans things up. Are there other targets I should use for a full test or is that accomplished with the make file? One little problem. The unix utility command `rm -f X*' produces an error message with there are no X* files. What is the way around that? I think that's normal. OK. With test54 removed, I've run several tests and they each produced an `ALL DONE'. Apparently that means everything worked? Or that nothing was tested :-). Here are the tests I ran: make -f Make_dos_sh.mak nongui make -f Make_dos_sh.mak small make -f Make_dos_sh.mak gui make -f Make_dos_sh.mak win32 The second test isn't much of a test :-) Why not have a test that tests all of them: vimall:TABfixff $(SCRIPTS16) $(SCRIPTS) $(SCRIPTS_GUI) $(SCRIPTS32) Otherwise we appear to redundantly test. This should be the first (default) test. I've added it to Make_ming.mak for testdir. The idea is that make gui runs all the tests that are possible for a Vim compiled with GUI, nongui for console Vim, etc. If you add them all together there won't be a Vim that manages to pass all the tests. -- I simultaneously try to keep my head in the clouds and my feet on the ground. Sometimes it's a stretch, though. -- Larry Wall /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Patch to try out: v:oldfiles
Now and then I start editing a file and want to go back to a file I edited in a previous edit session. But the name doesn't appear in the marks or buffer list. Still, I know the file name is in the viminfo file. There are plugins for this, but I thought it would be nice if Vim could retrieve file names natively. The idea is simple: when reading the viminfo file on startup, store the file names from the list of buffer marks in v:oldfiles. This already makes it possible to use them. For convenience I added the :oldfiles command to list them (nicer than :echo v:oldfiles). And the #N item to be able to use the file name in most places on the command line. Please try the patch and tell me what you think. - ERROR 047: Keyboard not found. Press RETURN to continue. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- oldfiles_patch.diff Description: Binary data
Bug in exception handling with :return
These two functions ought to behave identically, but don't... For some reason, the :catch never gets triggered for the Broken one. function! Working() try let y = x return y catch /^Vim\%((\a\+)\)\=:E121/ Handle 'Undefined variable' errors return 42 endtry endfunction function! Broken() try return x catch /^Vim\%((\a\+)\)\=:E121/ Handle 'Undefined variable' errors return 42 endtry endfunction ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Problem with CursorMoved AutoCommand when Editing Files on a Remote WIndows Share
Hello fellow Vimmers I've discovered a problem with Vim 7.2 when using the CursorMoved autocommand under Windows. The problem is only evident when editing files on a Windows share, rather than editing a file on the local machine. (Presumably the same issue is occurring even when editing on the local machine, but is only obvious when editing files on a Windows share.) The problem does not occur under Vim 7.1, so I conclude something has changed with how CursorMoved events are handled in Vim 7.2. Repro steps: I use the clever 'halfmove.vim' script created by Andy Spencer, which uses the CursorMoved autocommand on each keystroke. My problem can be easily repro'd: with the halfmove script in the \plugin folder, simply use Vim 7.2 to edit a file on some remote share (eg. 'vim \\FRED\barney.txt', barney.txt being some file on a remote machine named FRED). Then hold down the 'j' or 'k' keys to scroll the text window. The window scrolls very slowly and with fits and starts. In worst cases scrolling is so slow that barney.txt cannot usefully be edited. Network activity is also very high during the scrolling. Deleting the 'halfmove.vim' script from the \plugin folder, or (alternately) commenting out the CursorMoved autocommand from that script, cures the problem. Vim 7.2 then becomes as speedy as Vim 7.1. Since the issue does not occur for Vim 7.1, I'm sticking with Vim 7.1 for now (because I really like the functionality offered by the halfmove.vim script, and I have to edit quite a few files on remote shares). But evidently something significant has changed in how Vim 7.2 handles the CursorMoved event. Experiments show that the slowdown occurs even when CursorMoved is set up to call an empty (no-op) function; that is, it's not the work being done in the function that causes the slowdown, but the fact that CursorMoved is calling a Vim function at all. I've experimented with several of the source code files for 7.2 in an attempt to figure out why/where the issue is occurring, but so far haven't found a solution. Can anyone offer any insight? What changes were made in 7.2's handling of CursorMoved that might be causing this problem? I've seen the issue under both Vista and WinXP. I'm using the console mode version of Vim 7.2. Any help appreciated. Thanks --David Kotchan --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
