bug introduced by de6cb44

[thisirs]

I updated helm to last commit and i found a regression. Helm is no longer able to visit files from Locate or Recentf section in helm-for-files. I bisected and the culprit seems to be de6cb44!

[haxney]

Thanks for taking the time to bisect the regression! I'll take a look at it
when I'm done my exam ;)

Side note, we should probably start building up a test suite to catch
regressions like these.
On May 16, 2012 8:17 AM, "Sylvain Rousseau" <
reply@reply.github.com>
wrote:

I updated helm to last commit and i found a regression. Helm is no longer
able to visit files from Locate or Recentf section in helm-for-files. I
bisected and the culprit seems to be de6cb44!

---

Reply to this email directly or view it on GitHub:
#59

[dixie]

I'm happy it is known issue and not something weird with my emacs setup!

[bbatsov]

@haxney Test suite is always a good idea. ERT is part of Emacs 24 and there is also ecukes

[haxney]

@bbatsov That's what I'm thinking. It'd be a big boon to Emacs if there was a (relatively) comprehensive test suite.

Back on topic: @dixie I haven't yet checked whether I have that same regression. O time, how fleeting thou art! Did you check to see if it happens in emacs -Q? Also, what's your OS, Emacs version, etc?

[thierryvolpiatto]

@dixie Can't reproduce this bug here, all is working fine.
Please try from 'emacs -Q' as suggested by @haxney.
Also what mean "helm is not able to visit files"?
Describe exactly what you are doing from emacs -Q, turn on debug-on-error and send us the resulting backtrace if some.
Thanks.

[thisirs]

This was already tested with emacs -Q. At commit de6cb44^ the full path in helm-for-files is still visible, helm is visiting the file without any problem. At commit de6cb44 only the file names are visible, the basename part has been removed.

The problem is that when choosing an entry helm is trying to visit only the filename. helm is opening an empty buffer in `default-directory' that has the same name of the selected entry.

Too weird that i'm the only one having this problem!
Using GNU Emacs 24.0.96.1 on LMDE

Edit: problem is helm-c-highlight-files that has been moved from helm-c-source-files-in-current-dir to helm file attribute

[thierryvolpiatto]

Sylvain Rousseau
reply@reply.github.com
writes:

This was already tested with emacs -Q. At commit de6cb44^ the full
path in helm-for-files is still visible, helm is visiting the file
without any problem. At commit de6cb44 only the file names are
visible, the basename part has been removed.
This is not a problem, the candidates for files are now like:
(foo . "/full/path/to/foo").

The problem is that when choosing an entry helm is trying to visit
only the filename. helm is opening an empty buffer in
default-directory' that has the same name of the selected entry.
No, see above, when visiting a file e.g with find file, helm use the
cdr of the candidate, that is the full path even if on your display
you see only the basename of candidate.

Too weird that i'm the only one having this problem!
Try to be sure to not have some old library or personal stuff that load
when requiring helm. (e.g An old helm-files.el in your load path)

Try to send as explained in precedent post a full recipe:

--8<---------------cut here---------------start------------->8---
emacs -Q
(add-to-list 'load-path "/path/to/helm/dir") ; be sure to have only
; recent versions of files
; there.
(require 'helm-config)

M-x helm-for-files

Move to files in current directory source?
Try to open a file from there?
What happen?
etc...
--8<---------------cut here---------------end--------------->8---

Using GNU Emacs 24.0.96.1 on LMDE
Try to upgrade to 24.1, but it is not the problem I think; should works
with 24.0.96 too.

---

Reply to this email directly or view it on GitHub:
#59 (comment)

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[thisirs]

The issue is fixed by commit a4f260...