2

Normally when I run helm-find-files I'm immediately shown a list of files in the current directory. Sometimes, however, helm just gives me an empty window. I can start navigating my filesystem in that window like normal, but I have to start navigation from the root of my filesystem. It's as if helm didn't/couldn't figure out the directory of the file I'm editing.

For example, I see this problem if my cursor is at the very beginning of a typical HTLM file:

<!doctype html>
^ point is here

or at the end of a line with a meta tag:

    <meta charset="utf-8">
                          ^ point is here

If the point is anywhere else in those lines, helm-find-files works as expected. In those positions, though, it seems like helm gets confused.

So my question: Is this expected behavior? I know that helm is complex (heck, it's probably self-aware), and it may well be that this is the "correct" behavior somehow. If this is expected, can someone explain why? I just need a better mental model of what's going on.

If this is not expected behavior, I'll likely file an issue with helm. I just wanted to do some due diligence before that, though.

Improve this question

3 Answers 3

Reset to default
2

helm-find-files tries to interpret the text at point as a file path or an URL. This sometimes is really helpful, since in a free flowing text with filenames you can just position the cursor and jump to the correct path. But it gets confused in some cases. A particularly nagging one for me is its failure to interpret a standard file URL like file:/some/path correctly - but it deals fine with /some/path. The leading file: seems to confuse it, while it again works fine with URLs like http://some/url.

Improve this answer
2
  • Is there any way to turn this behavior off, or is it baked in? I've tried changing e.g. helm-ff-url-regexp but with no noticeable results.
    – abingham
    Commented Feb 13, 2015 at 8:23
  • I've opened an issue for this: github.com/emacs-helm/helm/issues/870
    – abingham
    Commented Feb 13, 2015 at 16:57
2

For this feature, Helm is using ffap ("find file at point"). Over at EmacsWiki, I found advice on how to make ffap behave better in HTML:

Ignore '/'

On unix based systems, / is the root path. So all string starts with / is recognized as a path.

This is annoying especially when editing HTML or XML. The following advice ignore / as a wrong result.

(defadvice ffap-file-at-point (after ffap-file-at-point-after-advice ())
  (if (string= ad-return-value "/")
      (setq ad-return-value nil)))
(ad-activate 'ffap-file-at-point)
;; (ad-deactivate 'ffap-file-at-point)

– tomykaira, feel free to use this snippet in any way.

It seems to work great. Real filenames are still recognized, but false positives (which made Helm fall back to '/') are not.

Improve this answer
1
  • How can I turn this on when the buffer have a major mode related to HTML activated?
    – shackra
    Commented Jul 24, 2016 at 4:46
0

When your helm prompt reads "Find Files or URL:" and you want the other helm way of finding/filtering you can hit C-c / and you should get the prompt "pattern:" with the more normal helm find.

I also use this in when C-x C-f in dired goes to a funny helm prompt.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.