Doesn't follow symbolic links
kankaristo opened this issue · 8 comments
Thanks for a fantastic package, this is a huge productivity boost!
I have a (small) SSD as my main drive, so I have some bigger projects on an HDD, with symbolic links to them in my home directory.
ag works fine with this, if I run it from the project directory (the symbolic link). However, atom-fuzzy-grep searches from my home dir instead, and ag doesn't follow the symlink from there.
ag --follow follows symlinks, but takes a really long time to finish (it's been running the entire time I've been writing this).
Does atom-fuzzy-grep always search in the home directory or does it get confused by the project root being a symlink?
ag --follow is still searching (after 20 minutes)...
@kankaristo, thanks for report! symlinked project as source for editor is a bit weird for me.
ag --follow follows symlinks, but takes a really long time to finish (it's been running the entire time I've been writing this).
May be there are a lot of symlinked files which cause performance issue for ag. I'm using this plugin for a big project also (~30k files) and it works nice for me on OSX and Linux.
Does atom-fuzzy-grep always search in the home directory or does it get confused by the project root being a symlink?
No. It use you project directory returned via atom api.
I think it's fairly common.
For example, if you're developing a package for Atom (with apm develop package-name), it creates a symlink from ~/.atom/dev/packages/package-name to ~/github/package-name (by default).
Agree, but why you should open symlinked source ~/.atom/dev/packages/package-name instead of original ~/github/package-name?
Ease of access mostly.
I have all of my projects in ~/projects/. Some of these are symlinks, some are regular directories. This way they are all in the same place (ease of access), instead of being spread around different drives, remote servers, etc.
I don't know if this would fix the issue, but this page mentions atom.project.relativizePath(filePath), which returns the project path for a given file path.
@kankaristo, thanks! I'll try it.
This is fixed in #7.