Patch 7.2.076
Patch 7.2.076
Problem:rename(from, to) deletes the file if from and to are not equal
but still refer to the same file. E.g., on a FAT32 filesystem
under Unix.
Solution: Go through another file name.
Files: src/fileio.c
*** ../vim-7.2.075/src/fileio.c Fri Nov 28 21:26:50 2008
--- src/fileio.cTue Dec 30 16:04:44 2008
***
*** 6119,6124
--- 6119,6165
if (mch_stat((char *)from, st) 0)
return -1;
+ #ifdef UNIX
+ {
+ struct stat st_to;
+ chartempname[MAXPATHL + 1];
+
+ /* It's possible for the source and destination to be the same file.
+* This happens when from and to differ in case and are on a FAT32
+* filesystem. In that case go through a temp file name. */
+ if (mch_stat((char *)to, st_to) = 0
+st.st_dev == st_to.st_dev
+st.st_ino == st_to.st_ino)
+ {
+ /* Find a name that doesn't exist and is in the same directory.
+* Move from to tempname and then to to. */
+ if (STRLEN(from) = MAXPATHL - 5)
+ return -1;
+ STRCPY(tempname, from);
+ for (n = 123; n 9; ++n)
+ {
+ sprintf(gettail(tempname), %d, n);
+ if (mch_stat(tempname, st_to) 0)
+ {
+ if (mch_rename((char *)from, tempname) == 0)
+ {
+ if (mch_rename(tempname, (char *)to) == 0)
+ return 0;
+ /* Strange, the second step failed. Try moving the
+* file back and return failure. */
+ mch_rename(tempname, (char *)from);
+ return -1;
+ }
+ /* If it fails for one temp name it will most likely fail
+* for any temp name, give up. */
+ return -1;
+ }
+ }
+ return -1;
+ }
+ }
+ #endif
+
/*
* Delete the to file, this is required on some systems to make the
* mch_rename() work, on other systems it makes sure that we don't have
*** ../vim-7.2.075/src/version.cWed Dec 24 14:24:41 2008
--- src/version.c Tue Dec 30 16:09:51 2008
***
*** 678,679
--- 678,681
{ /* Add new patch number below this line */
+ /**/
+ 76,
/**/
--
FATAL ERROR! SYSTEM HALTED! - Press any key to continue doing nothing.
/// Bram Moolenaar -- b...@moolenaar.net -- 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: Patch 7.2.076
On 30/12/08 16:16, Bram Moolenaar wrote: Patch 7.2.076 Problem:rename(from, to) deletes the file if from and to are not equal but still refer to the same file. E.g., on a FAT32 filesystem under Unix. Solution: Go through another file name. Files:src/fileio.c [...] Compiles OK, but: fileio.c: In function ‘vim_rename’: fileio.c:6141: warning: pointer targets in passing argument 1 of ‘gettail’ differ in signedness fileio.c:6141: warning: pointer targets in passing argument 1 of ‘sprintf’ differ in signedness Best regards, Tony. -- We have the flu. I don't know if this particular strain has an official name, but if it does, it must be something like Martian Death Flu. You may have had it yourself. The main symptom is that you wish you had another setting on your electric blanket, up past HIGH, that said ELECTROCUTION. Another symptom is that you cease brushing your teeth, because (a) your teeth hurt, and (b) you lack the strength. Midway through the brushing process, you'd have to lie down in front of the sink to rest for a couple of hours, and rivulets of toothpaste foam would dribble sideways out of your mouth, eventually hardening into crusty little toothpaste stalagmites that would bond your head permanently to the bathroom floor, which is how the police would find you. You know the kind of flu I'm talking about. -- Dave Barry, Molecular Homicide --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.2.072 (extra)
Tony, your patch applies correctly. Will the corrected patch be moved to ftp://ftp.vim.org/pub/vim/patches/7.2 at some point (and the md5sum updated)? Thanks, Chad Harp --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.2.072 (extra)
On 30/12/08 16:47, harpchad wrote: Tony, your patch applies correctly. Will the corrected patch be moved to ftp://ftp.vim.org/pub/vim/patches/7.2 at some point (and the md5sum updated)? Thanks, Chad Harp I hope so, but only Bram can give the answer to that. Best regards, Tony. -- Adult, n.: One old enough to know better. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Files in ftdetect dirs are not searched
I have added several directories to my runtimepath, each corresponding to a git repository. For example, I have a directory ~/Projects/vim- rack that contains ftdetect/rack.vim and syntax/rack.vim. I'm able to manually :set filetype=rack (i.e. the syntax/rack.vim file is picked up), but the ftdetect file does not work. It works fine if I create a symlink at ~/.vim/ftdetect/rack.vim. It seems there's a bug in the way ftdetect files are sourced. This feeling is amplified by the fact that I can insert syntax errors into ~/Projects/vim-rack/ftdetect/rack.vim without Vim complaining on startup. I hope there's a simple workaround. Cheers, Daniel Schierbeck --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Vim and Python 3.0 incompatibilities
Since Python 3.0 is incompatible with earlier versions of Python, it is also incompatible with Vim 7.2, apparently due to changes in the C interface. I first brought this up on the vim_use mailing list, but it seems to be more of development issue since it deals with Vim's source code. (original discussionhttp://groups.google.com/group/vim_use/browse_thread/thread/4aaceb7ee66e68fb/d5ea6610cbe365dd?hl=enlnk=gst ) PEP 3123 http://www.python.org/dev/peps/pep-3123/ seems to be the source of some of the problems, since PyObject_HEAD works in a different way in Python 3.0 than how it's used in Vim. I don't know C very well, so I'm not sure what needs to be changed beyond that. What changes are needed to make Vim work with Python 3.0, and can those changes be made without becoming incompatible with earlier versions of Python? Daniel Hast --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Files in ftdetect dirs are not searched
On 30/12/08 19:14, Daniel Schierbeck wrote: I have added several directories to my runtimepath, each corresponding to a git repository. For example, I have a directory ~/Projects/vim- rack that contains ftdetect/rack.vim and syntax/rack.vim. I'm able to manually :set filetype=rack (i.e. the syntax/rack.vim file is picked up), but the ftdetect file does not work. It works fine if I create a symlink at ~/.vim/ftdetect/rack.vim. It seems there's a bug in the way ftdetect files are sourced. This feeling is amplified by the fact that I can insert syntax errors into ~/Projects/vim-rack/ftdetect/rack.vim without Vim complaining on startup. I hope there's a simple workaround. Cheers, Daniel Schierbeck $VIMRUNTIME/filetype.vim (current version, 2008 Dec 08) includes the following at lines 2419-2421: Use the plugin-filetype checks last, they may overrule any of the previously detected filetypes. runtime! ftdetect/*.vim With an exclamation mark after :runtime, it will source every *.vim file in the ftdetect/ subdirectory of every directory in 'runtimepath'. This is done after normal filetype detection. So: 1) Is ~/Projects/vim-rack (without an ending slash) in your 'runtimepath' option? (Not its ftdetect subdirectory.) 2) If standard filetype detection finds a different default filetype, you set it using :setlocal filetype=rack, not :setfiletype rack, don't you? Best regards, Tony. -- How doth the little crocodile Improve his shining tail, And pour the waters of the Nile On every golden scale! How cheerfully he seems to grin, How neatly spreads his claws, And welcomes little fishes in, With gently smiling jaws! -- Lewis Carrol, Alice in Wonderland --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim and Python 3.0 incompatibilities
On 30/12/08 20:58, Daniel Hast wrote: Since Python 3.0 is incompatible with earlier versions of Python, it is also incompatible with Vim 7.2, apparently due to changes in the C interface. I first brought this up on the vim_use mailing list, but it seems to be more of development issue since it deals with Vim's source code. (original discussion http://groups.google.com/group/vim_use/browse_thread/thread/4aaceb7ee66e68fb/d5ea6610cbe365dd?hl=enlnk=gst) PEP 3123 http://www.python.org/dev/peps/pep-3123/ seems to be the source of some of the problems, since PyObject_HEAD works in a different way in Python 3.0 than how it's used in Vim. I don't know C very well, so I'm not sure what needs to be changed beyond that. What changes are needed to make Vim work with Python 3.0, and can those changes be made without becoming incompatible with earlier versions of Python? Daniel Hast I don't know what changes need to be made, but I suppose they can be made without breaking compatibility, by making sure that when FEAT_PYTHON is defined, another #define has the Python version, and having conditional-compile #if lines testing that where necessary. This would, I suppose, involve changes to src/if_python.c and possibly elsewhere (configure maybe, and/or the various makefiles). AFAIK, no such changes have been brought into the Vim source yet, so unless you want to make and test them, or know someone who will, ATM if you want Vim with Python you're better off staying with Python 2.x Best regards, Tony. -- Why don't elephants eat penguins ? Because they can't get the wrappers off ... --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
if_python: vim.eval('recursive object') do not return recursive object.
vim.eval('recursive object') do not return recursive object. It returns
deeply nested object instead and each object do not point same object.
The attached patch fixes this problem.
Steps To Reproduce:
let x = {}
let x.x = x
let y = []
call add(y, y)
python EOF
import vim
x = vim.eval('x')
y = vim.eval('y')
print x is x['x']
print y is y[0]
print x
print y
EOF
Actual Results:
False
False
{'x': {'x': {...}}}
[[[...]]]
Expected Results:
True
True
{'x': {...}}
[[...]]
--
Yukihiro Nakadaira - yukihiro.nakada...@gmail.com
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: src/if_python.c
===
--- src/if_python.c (revision 1308)
+++ src/if_python.c (working copy)
@@ -1151,14 +1151,20 @@
/* Check if we run into a recursive loop. The item must be in lookupDict
* then and we can use it again. */
-sprintf(ptrBuf, PRINTF_DECIMAL_LONG_U, (long_u)our_tv);
-result = PyDict_GetItemString(lookupDict, ptrBuf);
-if (result != NULL)
- Py_INCREF(result);
-else if (our_tv-v_type == VAR_STRING)
+if (our_tv-v_type == VAR_LIST || our_tv-v_type == VAR_DICT)
{
+ sprintf(ptrBuf, PRINTF_DECIMAL_LONG_U, (long_u)our_tv-vval.v_list);
+ result = PyDict_GetItemString(lookupDict, ptrBuf);
+ if (result != NULL)
+ {
+ Py_INCREF(result);
+ return result;
+ }
+}
+
+if (our_tv-v_type == VAR_STRING)
+{
result = Py_BuildValue(s, our_tv-vval.v_string);
- PyDict_SetItemString(lookupDict, ptrBuf, result);
}
else if (our_tv-v_type == VAR_NUMBER)
{
@@ -1167,7 +1173,6 @@
/* For backwards compatibility numbers are stored as strings. */
sprintf(buf, %ld, (long)our_tv-vval.v_number);
result = Py_BuildValue(s, buf);
- PyDict_SetItemString(lookupDict, ptrBuf, result);
}
# ifdef FEAT_FLOAT
else if (our_tv-v_type == VAR_FLOAT)
@@ -1176,7 +1181,6 @@
sprintf(buf, %f, our_tv-vval.v_float);
result = Py_BuildValue(s, buf);
- PyDict_SetItemString(lookupDict, ptrBuf, result);
}
# endif
else if (our_tv-v_type == VAR_LIST)
@@ -1185,10 +1189,11 @@
listitem_T *curr;
result = PyList_New(0);
- PyDict_SetItemString(lookupDict, ptrBuf, result);
if (list != NULL)
{
+ PyDict_SetItemString(lookupDict, ptrBuf, result);
+
for (curr = list-lv_first; curr != NULL; curr = curr-li_next)
{
newObj = VimToPython(curr-li_tv, depth + 1, lookupDict);
@@ -1200,7 +1205,6 @@
else if (our_tv-v_type == VAR_DICT)
{
result = PyDict_New();
- PyDict_SetItemString(lookupDict, ptrBuf, result);
if (our_tv-vval.v_dict != NULL)
{
@@ -1209,6 +1213,8 @@
hashitem_T *hi;
dictitem_T *di;
+ PyDict_SetItemString(lookupDict, ptrBuf, result);
+
for (hi = ht-ht_array; todo 0; ++hi)
{
if (!HASHITEM_EMPTY(hi))
Re: Files in ftdetect dirs are not searched
On Tue, Dec 30, 2008 at 1:14 PM, Daniel Schierbeck wrote: I have added several directories to my runtimepath, each corresponding to a git repository. For example, I have a directory ~/Projects/vim- rack that contains ftdetect/rack.vim and syntax/rack.vim. I'm able to manually :set filetype=rack (i.e. the syntax/rack.vim file is picked up), but the ftdetect file does not work. It works fine if I create a symlink at ~/.vim/ftdetect/rack.vim. It seems there's a bug in the way ftdetect files are sourced. This feeling is amplified by the fact that I can insert syntax errors into ~/Projects/vim-rack/ftdetect/rack.vim without Vim complaining on startup. I hope there's a simple workaround. Sorry I couldn't come up with the solution earlier on IRC, but after some sleep, I think I see what's going wrong here. 10 to 1 says you're using a 'nix distro that installs a default system-wide vimrc, and that system-wide vimrc does 'filetype on', meaning that $VIMRUNTIME/filetype.vim gets loaded before your ~/.vimrc ever adds your runtimepaths onto the default runtimepath, and only the ftdetect directories in the default runtimepath are used. I'm not really sure what to do about that, though. You could remove the system-wide vimrc entirely, and move anything done in it to your ~/.vimrc after your change to runtimepath... but this seems ugly as it affects other users. You could alias vim=vim --cmd 'set rtp^=yourdir' in your shell rc, but that also seems horrifically ugly. You could redo the runtime! ftdetect/*.vim, but that would make any autocmds from *other* directories in the runtimepath be re-added... I think the nicest thing to do would be to save the existing value of the 'runtimepath' option, overwrite it with *just* the directories you want added, do the runtime! ftdetect/*.vim, reset 'runtimepath' back to its old value, and then add the new paths to that option in the right spots... but that seems like a whole lot of work for this. Anyone see any better solutions? It's a shame there are no autocmds for an option being set... ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
