Re: Files in ftdetect dirs are not searched
On 31/12/08 07:48, Matt Wozniski wrote: 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 could use :filetype off :filetype on after changing your 'runtimepath', which would first unset the filetype-detection autocommands, and then re-source filetype.vim to set them again with the new 'runtimepath' (invoking your ftdetect/*.vim scripts). See :help :filetype-overview. Or if the reason is that you change 'runtimepath' after invoking :filetype plugin indent on or after sourcing vimrc_example.vim, do it before. The location of a possible system-wide vimrc is shown near the middle of the output of the :version command. If you compile your own Vim with the vim-default settings, it will look for a system vimrc at /usr/local/share/vim/vimrc, which is almost certainly different of the location (typically /etc/vimrc) used by a Vim version distributed together with a Linux distro. See my compiling HowTo for Unix/Linux at http://users.skynet.be/antoine.mechelynck/vim/compunix.htm Best regards, Tony. -- If A equals success, then the formula is A = X + Y + Z. X is work. Y is play. Z is keep your mouth shut. -- Albert Einstein --~--~-~--~~~---~--~~ 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 Wed, Dec 31, 2008 at 8:11 AM, Tony Mechelynck wrote: On 31/12/08 07:48, Matt Wozniski wrote: On Tue, Dec 30, 2008 at 1:14 PM, Daniel Schierbeck wrote: 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 use :filetype off :filetype on after changing your 'runtimepath', which would first unset the filetype-detection autocommands, and then re-source filetype.vim to set them again with the new 'runtimepath' (invoking your ftdetect/*.vim scripts). Yes, then that seems like the best solution. I hadn't thought that :filetype off | filetype on would reload filetype.vim, but now that I think about it it makes sense. So, that's the solution, then. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: if_python: vim.eval('recursive object') do not return recursive object.
Yukihiro Nakadaira wrote:
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': {...}}
[[...]]
Thanks, I'll look into it later.
It would be good if a few people try it out and let us know how it
works.
--
To keep milk from turning sour: Keep it in the cow.
/// 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
Tony Mechelynck wrote: 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 I quickly fixed the serious problem that a file could be deleted when renaming it. I'm now also fixing that rename(foo, FOO) doesn't work on systems where the file name case is kept but ignored when finding a file. I'll also fix the warnings. -- The most powerful force in the universe is gossip. /// 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
Dominique Pelle wrote:
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
*** ../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)
+ {
[...]
Will the stat() technique to find whether 2 files are identical work on
all FAT file systems?
I think remembering that FAT file systems don't have the concept of
inodes, unlike Unix file systems, so stat() either leaves st_ino as 0,
or synthesizes a fake inode number. I will try it later when I have time.
Inodes must work on any file system. It is a basic concept in Unix. If
st_ino doesn't have a valid value that you should not use that file
system, many tools will not work.
--
People who want to share their religious views with you
almost never want you to share yours with them.
/// 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 31/12/08 14:58, Bram Moolenaar wrote: Dominique Pelle wrote: [...] I think remembering that FAT file systems don't have the concept of inodes, unlike Unix file systems, so stat() either leaves st_ino as 0, or synthesizes a fake inode number. I will try it later when I have time. Inodes must work on any file system. It is a basic concept in Unix. If st_ino doesn't have a valid value that you should not use that file system, many tools will not work. FAT filesystems have the concept of cluster number which is an integer between 2 and (at most) 2^n-16 (I think) (where n=12, 16 or 32 depending on the FAT type) and representing the ordinal location on the partition (or diskette) of a block of data which must be allocated as a unit. The cluster size (as a number of physical records) is determined when the partition is formatted; it is usually 512 bytes times a power of 2. The directory entry for every file (or subdirectory) includes the number of its first cluster; the FAT (File Allocation Table) entry for every cluster on the partition holds either the number of the next cluster in the same file, or a code meaning that this is the last cluster of the file, that it is not allocated to any file, or that it is a known bad cluster. I'm not 100% sure what an inode means on Unix filesystems but I think this is the FAT equivalent. Best regards, Tony. -- There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened. -- Douglas Adams, The Hitchhiker's Guide to the Galaxy --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Patch 7.2.077
Patch 7.2.077 (after 7.2.076)
Problem:rename(from, to) doesn't work if from and to differ only in
case on a system that ignores case in file names.
Solution: Go through another file name.
Files: src/fileio.c
*** ../vim-7.2.076/src/fileio.c Tue Dec 30 16:15:16 2008
--- src/fileio.cWed Dec 31 14:59:59 2008
***
*** 6106,6117
#ifdef HAVE_ACL
vim_acl_T acl;/* ACL from original file */
#endif
/*
! * When the names are identical, there is nothing to do.
*/
if (fnamecmp(from, to) == 0)
! return 0;
/*
* Fail if the from file doesn't exist. Avoids that to is deleted.
--- 6106,6129
#ifdef HAVE_ACL
vim_acl_T acl;/* ACL from original file */
#endif
+ #if defined(UNIX) || defined(CASE_INSENSITIVE_FILENAME)
+ int use_tmp_file = FALSE;
+ #endif
/*
! * When the names are identical, there is nothing to do. When they refer
! * to the same file (ignoring case and slash/backslash differences) but
! * the file name differs we need to go through a temp file.
*/
if (fnamecmp(from, to) == 0)
! {
! #ifdef CASE_INSENSITIVE_FILENAME
! if (STRCMP(gettail(from), gettail(to)) != 0)
! use_tmp_file = TRUE;
! else
! #endif
! return 0;
! }
/*
* Fail if the from file doesn't exist. Avoids that to is deleted.
***
*** 6122,6128
#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
--- 6134,6139
***
*** 6130,6162
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
--- 6141,6182
if (mch_stat((char *)to, st_to) = 0
st.st_dev == st_to.st_dev
st.st_ino == st_to.st_ino)
+ use_tmp_file = TRUE;
+ }
+ #endif
+
+ #if defined(UNIX) || defined(CASE_INSENSITIVE_FILENAME)
+ if (use_tmp_file)
+ {
+ chartempname[MAXPATHL + 1];
+
+ /*
+* Find a name that doesn't exist and is in the same directory.
+* Rename from to tempname and then rename tempname to to.
+*/
+ if (STRLEN(from) = MAXPATHL - 5)
+ return -1;
+ STRCPY(tempname, from);
+ for (n = 123; n 9; ++n)
{
! sprintf((char *)gettail((char_u *)tempname), %d, n);
! if (mch_stat(tempname, st) 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
*** ../vim-7.2.076/src/version.cTue Dec 30 16:15:16 2008
--- src/version.c Wed Dec 31 16:19:29 2008
***
*** 678,679
--- 678,681
{ /* Add new patch number below this line */
+ /**/
+ 77,
/**/
--
We apologise again for the fault in the subtitles. Those responsible for
sacking the people who have just been sacked have been sacked.
Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote
