search

bbatsov / helm-projectile

Helm UI for Projectile
329 stars 71 forks source link

'helm-projectile-find-file' fails to open files #69

Closed maksut closed 7 years ago

maksut commented 7 years ago

Expected behavior

Open a .projectile file from a non-empty test folder. The folder is not under source control. Then 'helm-projectile-find-file'.

Interactive fuzzy matching should work and the selected file should be opened.

Actual behavior

Fuzzy matching behavior is strange. It does not select the matched file. After selecting an item, emacs tries to create a directory with the concatenated value of all the candidates except the last one:

Notes

I think this is introduced by this: Use (DISPLAY . REAL) candidates. The version before the commit is fine. I've tried to narrow it down further but I don't have enough "elisp fu" it seems.

Environment & version information

helm-projectile-20170125.1815 helm-20170128.1257 projectile-20170106.606 GNU Emacs 25.1.1 (x86_64-w64-mingw32) of 2016-09-22 Windows 7

xiongtx commented 7 years ago

I don't have a Windows machine handy, but I cannot reproduce this on my MacBook.

Can you try upgrading all related packages (helm, projectile, helm-projectile) and see if it still occurs?

maksut commented 7 years ago

@xiongtx I use spacemacs. After updated all packages, the problem still exists. Current versions:

But I realized something else, it works if the project is under source control (git) or I force native index with:

(setq projectile-indexing-method 'native)

This must be a problem related to an external tool. I have C:\msys64\usr\bin in my path. It has standard tools like find, git, grep. I also tried use Cygwin binaries instead, didn't make a difference.

xiongtx commented 7 years ago

Can you try this with regular projectile-find-file? We should first determine if the problem is indeed caused by helm-projectile, or if it affects projectile without helm.

maksut commented 7 years ago

It is the find output. In my system find adds the prefix ./ for each item:

I was able to workaround by dropping the ./ prefixes with sed:

(setq projectile-generic-command "find . -type f -print0 | sed 's#^\\./##g'")

Without the workaround, fuzzy match of projectile-find-file still seems off. It doesn't move the most suitable match to top. But it at least opens the selected file (instead of trying to create a directory). Anyhow it might still be a projectile defect.

Also remember; before "Use (DISPLAY . REAL) candidates" change it was working fine.

xiongtx commented 7 years ago

find lists files with a leading ./ for me as well. It's not causing a problem.

Also remember; before "Use (DISPLAY . REAL) candidates" change it was working fine.

If this problem occurs with projectile-find-file without helm, then it's not an issue introduced by helm-projectile.

Can you confirm that this problem occurs with projectile-find-file without helm-projectile? That is with,

(helm-projectile-toggle -1)

Also be sure to restart Spacemacs after upgrading your packages.

maksut commented 7 years ago

I couldn't figure out how to test it with (helm-projectile-toggle -1). I normally use spacemacs. I have no idea how spacemacs (or helm on that matter) puts all these packages together.

But for testing I set up a bare emacs + projectile config and projectile-find-file works as expected. I made sure that it uses the external find. The version of the projectile and emacs is same with the previous set up.

maksut commented 7 years ago

OK. This is not a helm-projectile issue.

It also happens with spacemacs using ivy. Specifically counsel-projectile-find-file similarly fails with external find. And the same workaround works for counsel-projectile.

So although projectile-find-file works fine, the integration projects like helm-projectile or counsel-projectile has the problem.

Thanks for your time. I might raise this in projectile if I feel adventurous :)