Nazri Ramliy wrote:
> On Fri, Feb 20, 2009 at 9:22 PM, Nazri Ramliy <[email protected]> wrote: > > There's one major outstanding issue that I'm aware of - it does not > > skip symbolic links. This may result in infinite cycle if there exists > > a symbolic link that creates a cycle in the file system. > > Attached patch makes it skip symbolic links to directory on unix platform. > I don't know how to do the same for other platforms (amiga?/windows?), > sorry :) Cycles in symbolic links are rare. The code should be able to handle this, in a way that it doesn't drop all results that contain a symbolic link. Thus symbolic links should be followed, unless getting to a directory that was previously visited. > > I don't have access to a windows platform so I can't test the patch on > > windows. It may have problems with those different drive letters. > > Upon further thoughts (on my limited brain capacity :), I think that it won't > have any problem when doing the expansion and uniquefying of the files > in the 'path' option. > > For example with 'path' is set to C:/**,D:/**, doing ":find file1<tab>", > matching files like > > C:\a\file1.txt and > D:\a\file1.txt > > would be listed using their full path names in the wildmenu listing while > files like > > C:\project1\a\file1.txt and > D:\project2\a\file2.txt > > would be shortened to > > project1\a\file1.txt and > project2\a\file2.txt > > If anybody would verify that it works fine on windows platform (and/or any > other platform for that matter), that would be nice. > > I've sort of stress-tested this feature by setting my path to /** (the > whole root > directory, up to the default 30 directories deep), and then searching for some > known file using part of its filename. I did an strace on the vim process (to > see the chdir system calls that it made) and also looked at its memory usage > in top during the whole searching process. All seemed to be fine. Anyway, the patch adds a lot of code. I'm wondering if we can reuse more of the existing code. How about using globpath()? Or use find_file_in_path(), like ex_find() does (also accepting directories though). The last one also takes care of removing duplicates. If your code is to be used, the chdir() calls are not safe. Look at the mch_FullName() function in os_unix.c, lots of remarks about this. Yet another reason to use as much of the existing code, that has been debugged for a long time, instead of introducing new code which new problems. Also, the functions potentially take a lot of time, so they should check for CTRL-C now and then. That means calling ui_breakcheck() and checking the got_int flag. -- "Hit any key to continue" does _not_ mean you can hit the on/off button! /// 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 -~----------~----~----~----~------~----~------~--~---
