RE: Working directory problems
Ok, I'm pretty sure it isn't a vim bug. The reason why it appeared to be occasionally was that the path works fine for files that have been opened before in this session. Because my vim sessions tend to last for weeks it just appears random because I forget which files I have opened. Basically if I open a new vim session and open a file such that the working directory is c:\halo3\main\source, and the file is ai\actors.cpp. There are then two paths by which I might open a file, as follows: 1. Explicitly do an :sf into the file, or a :find. In this case the path will work correctly, and the path for that file will always be correct. 2. Execute some other command such as :ta tag which opens a new file. In this case the path for the file will be incorrect (namely it will be the absolute rather than relative path). Some time later, if I have closed that split and then try to open the file with :sf, it will open with the absolute path again. I suspect I'm going to have to write some BufEnter au command to deal with this, not really a problem now that I know what is going on! Cheers, Max -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Saturday, June 17, 2006 12:30 PM To: Max Dyckhoff Cc: vim@vim.org Subject: Re: Working directory problems Max Dyckhoff wrote: I have some issues with the working directory in vim that I really cannot get to the bottom of. I have tried looking through the help, and I've searched the Interweb too, to no avail, so I thought I would turn to this trusty mailing list! I operate a single vim instance with multiple files open in multiple splits. The common working directory for my code files is c:\project\main\source\, and the majority of the files therein lie in ai\filename. Normally the vim split status line shows the file as being ai\filename, namely the relative path from the working directory of c:\project\main\source\. When I open a new file - which I invariably do using sf filename, as I have all the appropriate directories in my path - occasionally the statusline shows as the absolute path, namely c:\project\main\source\ai\filename. If I perform the command cd c:\project\main\source, then the status line fixes itself. It should be noted that the status line is only incorrect for the new file; existing files are still fine. occasionally is the key here. Can you figure out when this happens? -- Just think of all the things we haven't thought of yet. /// 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 ///
RE: Working directory problems
I'm trying to identify a pattern in the madness, but so far as I can see it is just randomly. Sometimes I think I have found concrete reproduction steps, but then I repeat them in a clean environment and it doesn't happen, but a while later it happens again. Give me time, I'll get to the bottom of it! MAx -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Saturday, June 17, 2006 12:30 PM To: Max Dyckhoff Cc: vim@vim.org Subject: Re: Working directory problems Max Dyckhoff wrote: I have some issues with the working directory in vim that I really cannot get to the bottom of. I have tried looking through the help, and I've searched the Interweb too, to no avail, so I thought I would turn to this trusty mailing list! I operate a single vim instance with multiple files open in multiple splits. The common working directory for my code files is c:\project\main\source\, and the majority of the files therein lie in ai\filename. Normally the vim split status line shows the file as being ai\filename, namely the relative path from the working directory of c:\project\main\source\. When I open a new file - which I invariably do using sf filename, as I have all the appropriate directories in my path - occasionally the statusline shows as the absolute path, namely c:\project\main\source\ai\filename. If I perform the command cd c:\project\main\source, then the status line fixes itself. It should be noted that the status line is only incorrect for the new file; existing files are still fine. occasionally is the key here. Can you figure out when this happens? -- Just think of all the things we haven't thought of yet. /// 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 ///
RE: Working directory problems
Thanks! I'm working on a deadline today but will see if I can integrate this and make things work on Monday. Max -Original Message- From: Eric Arnold [mailto:[EMAIL PROTECTED] Sent: Friday, May 26, 2006 5:57 AM To: Max Dyckhoff Cc: vim@vim.org Subject: Re: Working directory problems Try something like this: set noshellslash let f = 'c:\topdir\main\source\ai\somefile' let f = expand(f) let f =fnamemodify( f, escape( ':p:s?c:\topdir\main\source\??', '\\' ) ) This will give you the relative path, providing that the path head remains consistent. This should strip off any pathnames it detects from path: function! GetPathRelative( f ) let f = expand( a:f ) let f =fnamemodify( f, ':p', ) let longest = '' for dir in split( path, ',' ) let dir = expand( dir ) if stridx( f, dir ) == 0 f != dir if strlen( dir ) strlen( longest ) let longest = dir endif endif endfor if longest != '' let f = strpart( f, strlen( longest ) ) let f = substitute( f, '^[/\\]*', '', '' ) endif return f endfunction let f = GetPathRelative( 'c:\topdir\main\source\ai\somefile') echomsg f let f = expand(%:p) echomsg f let f = GetPathRelative( f ) echomsg f On 5/25/06, Max Dyckhoff [EMAIL PROTECTED] wrote: I'm sorry, the script which I call basically just makes a system call: function! SDCheckout() let file = expand(%) if (confirm(Checkout from Source Depot?\n\n . file, Yes\nNo, 1) == 1) call system(sd edit . file . /dev/null) if v:shell_error == 0 set noreadonly edit! else if (confirm(An error occured!, Oh no!, 1) == 1) endif endif endif endfunction Sorry for the wrapping problems. I'm not entirely sure what you are suggesting doing with :h and :s??, but would I not suffer the problem of not knowing which subdirectory the file was in? Surely this isn't something that should need to be fixed, rather it should Just Work? Thanks! Max -Original Message- From: Eric Arnold [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 8:10 PM To: Max Dyckhoff Cc: vim@vim.org Subject: Re: Working directory problems I'm not sure how your bound function works. Have you tried using fnamemodify() to manipulate the filename? You can use the :h option to strip the path, and :s?? to substitute the relative path. On 5/24/06, Max Dyckhoff [EMAIL PROTECTED] wrote: Hi, I have some issues with the working directory in vim that I really cannot get to the bottom of. I have tried looking through the help, and I've searched the Interweb too, to no avail, so I thought I would turn to this trusty mailing list! I operate a single vim instance with multiple files open in multiple splits. The common working directory for my code files is c:\project\main\source\, and the majority of the files therein lie in ai\filename. Normally the vim split status line shows the file as being ai\filename, namely the relative path from the working directory of c:\project\main\source\. When I open a new file - which I invariably do using sf filename, as I have all the appropriate directories in my path - occasionally the statusline shows as the absolute path, namely c:\project\main\source\ai\filename. If I perform the command cd c:\project\main\source, then the status line fixes itself. It should be noted that the status line is only incorrect for the new file; existing files are still fine. Now I wouldn't normally be bothered by this, but I have a function in vim which I have bound to F6 that will check the current source file out of our source depot, and if the status line is showing the absolute path then it will fail, because the information about the source depot lies only within the c:\project\main directories. God, I hope that makes sense. It seems like such a trivial problem, but it really irks me, and I wonder if anyone could give me a hand! Cheers, Max -- Max Dyckhoff AI Engineer Bungie Studios
RE: Working directory problems
I'm sorry, the script which I call basically just makes a system call: function! SDCheckout() let file = expand(%) if (confirm(Checkout from Source Depot?\n\n . file, Yes\nNo, 1) == 1) call system(sd edit . file . /dev/null) if v:shell_error == 0 set noreadonly edit! else if (confirm(An error occured!, Oh no!, 1) == 1) endif endif endif endfunction Sorry for the wrapping problems. I'm not entirely sure what you are suggesting doing with :h and :s??, but would I not suffer the problem of not knowing which subdirectory the file was in? Surely this isn't something that should need to be fixed, rather it should Just Work? Thanks! Max -Original Message- From: Eric Arnold [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 8:10 PM To: Max Dyckhoff Cc: vim@vim.org Subject: Re: Working directory problems I'm not sure how your bound function works. Have you tried using fnamemodify() to manipulate the filename? You can use the :h option to strip the path, and :s?? to substitute the relative path. On 5/24/06, Max Dyckhoff [EMAIL PROTECTED] wrote: Hi, I have some issues with the working directory in vim that I really cannot get to the bottom of. I have tried looking through the help, and I've searched the Interweb too, to no avail, so I thought I would turn to this trusty mailing list! I operate a single vim instance with multiple files open in multiple splits. The common working directory for my code files is c:\project\main\source\, and the majority of the files therein lie in ai\filename. Normally the vim split status line shows the file as being ai\filename, namely the relative path from the working directory of c:\project\main\source\. When I open a new file - which I invariably do using sf filename, as I have all the appropriate directories in my path - occasionally the statusline shows as the absolute path, namely c:\project\main\source\ai\filename. If I perform the command cd c:\project\main\source, then the status line fixes itself. It should be noted that the status line is only incorrect for the new file; existing files are still fine. Now I wouldn't normally be bothered by this, but I have a function in vim which I have bound to F6 that will check the current source file out of our source depot, and if the status line is showing the absolute path then it will fail, because the information about the source depot lies only within the c:\project\main directories. God, I hope that makes sense. It seems like such a trivial problem, but it really irks me, and I wonder if anyone could give me a hand! Cheers, Max -- Max Dyckhoff AI Engineer Bungie Studios
Working directory problems
Hi, I have some issues with the working directory in vim that I really cannot get to the bottom of. I have tried looking through the help, and I've searched the Interweb too, to no avail, so I thought I would turn to this trusty mailing list! I operate a single vim instance with multiple files open in multiple splits. The common working directory for my code files is c:\project\main\source\, and the majority of the files therein lie in ai\filename. Normally the vim split status line shows the file as being ai\filename, namely the relative path from the working directory of c:\project\main\source\. When I open a new file - which I invariably do using sf filename, as I have all the appropriate directories in my path - occasionally the statusline shows as the absolute path, namely c:\project\main\source\ai\filename. If I perform the command cd c:\project\main\source, then the status line fixes itself. It should be noted that the status line is only incorrect for the new file; existing files are still fine. Now I wouldn't normally be bothered by this, but I have a function in vim which I have bound to F6 that will check the current source file out of our source depot, and if the status line is showing the absolute path then it will fail, because the information about the source depot lies only within the c:\project\main directories. God, I hope that makes sense. It seems like such a trivial problem, but it really irks me, and I wonder if anyone could give me a hand! Cheers, Max -- Max Dyckhoff AI Engineer Bungie Studios
Re: Working directory problems
I'm not sure how your bound function works. Have you tried using fnamemodify() to manipulate the filename? You can use the :h option to strip the path, and :s?? to substitute the relative path. On 5/24/06, Max Dyckhoff [EMAIL PROTECTED] wrote: Hi, I have some issues with the working directory in vim that I really cannot get to the bottom of. I have tried looking through the help, and I've searched the Interweb too, to no avail, so I thought I would turn to this trusty mailing list! I operate a single vim instance with multiple files open in multiple splits. The common working directory for my code files is c:\project\main\source\, and the majority of the files therein lie in ai\filename. Normally the vim split status line shows the file as being ai\filename, namely the relative path from the working directory of c:\project\main\source\. When I open a new file - which I invariably do using sf filename, as I have all the appropriate directories in my path - occasionally the statusline shows as the absolute path, namely c:\project\main\source\ai\filename. If I perform the command cd c:\project\main\source, then the status line fixes itself. It should be noted that the status line is only incorrect for the new file; existing files are still fine. Now I wouldn't normally be bothered by this, but I have a function in vim which I have bound to F6 that will check the current source file out of our source depot, and if the status line is showing the absolute path then it will fail, because the information about the source depot lies only within the c:\project\main directories. God, I hope that makes sense. It seems like such a trivial problem, but it really irks me, and I wonder if anyone could give me a hand! Cheers, Max -- Max Dyckhoff AI Engineer Bungie Studios