Take the 2-minute tour ×

I found the function here for replace filen at point but it doesn't seem to work properly: http://www.emacswiki.org/emacs/InsertFileName. It correctly finds the file-at-point but the replace appears to take the file you input and not the file detected originally from what I can see. I'm not sure how to fix this.

If I Run the function on /home/testfile

First it says file to replace so for example: /home/secondfile Then it says replace '/home/secondfile' with: /home/secondfile and then it says: No file at point

Any ideas??

Here is the function:

(autoload 'ffap-guesser "ffap")
(autoload 'ffap-read-file-or-url "ffap")

(defun my-replace-file-at-point (currfile newfile)
"Replace CURRFILE at point with NEWFILE.

  When interactive, CURRFILE will need to be confirmed by user
  and will need to exist on the file system to be recognized,
  unless it is a URL.

  NEWFILE does not need to exist.  However, Emacs's minibuffer
  completion can help if it needs to be.

 (let ((currfile (ffap-read-file-or-url "Replace filename: "
   (list currfile
         (ffap-read-file-or-url (format "Replace `%s' with: "
                                        currfile) currfile))))
  (if (or (looking-at (regexp-quote currfile))
          (let ((filelen (length currfile))
                (opoint (point))
                (limit (+ (point) (length currfile))))
              (goto-char (1- filelen))
              (and (search-forward currfile limit
                   (< (match-beginning 0) opoint))
                   (>= (match-end 0) opoint))))
      (replace-match newfile)
    (error "No file at point to replace"))))
share|improve this question
add comment

2 Answers

up vote 1 down vote accepted

There are probably a few things wrong/going on here. The first is, your point position when you are executing this. The second is, if you are using /home/user/something, that there is a strong possibility you will have mismatch between /home/user/something and ~/something (ffap returns the latter while at the point you may have written the former).


The use of looking-at with the regexp quoted filename expects the point to be at the beginning: e.g. |/home/user/something.

Its partner, looking-back expects /home/user/something|. Being somewhere in the middle will throw this error.

One quick fix for this is changing looking-at to thing-at-point-looking-at.


If you have written /home/user/something, ffap functions (in my case) shorten this using ~. There are probably some settings that govern this, but the easiest, quick fix I know of is using expand-file-name. This will take care of the first case, and if it is written as ~/something, the save-excursion body will replace it in the alternate case.

The only negative result I see is that, you might sometimes replace:

/home/user/something with ~/somethingelse

But, anyways, these two quick fixes just result in this complete change:

(thing-at-point-looking-at (regexp-quote (expand-file-name currfile)))

share|improve this answer
Thanks!! Yup that was it that it doesn't work properly on full path names unless you use expand-file-name but as you said replaces it with the shortened version. Is there anyway easily to force it to expand if it was already expanded or maybe preferably just expand the file name if a prefix arg (C-u) is passed in to the function. –  J Spen Aug 6 '12 at 22:46
add comment

can't see where "ffap-guesser" is defined. Looks like a bug.

Maybe try instead


share|improve this answer
Sorry I forgot to add the autoloads. It is defined in "ffap.el" but that doesn't seem to be where my issue lies. It recognizes the file-at-point correctly as far as I can tell but it seems to be in the function to replace the contents. Replace seems to take the file I want to replace instead of the original function so when the search occurs it doesn't find what it's supposed to replace. I could be wrong about this. –  J Spen Aug 4 '12 at 10:42
Also added an example of the exact steps of what occurs. If I usedfind-file-at-point could I just replace this with ffap-guesser?? –  J Spen Aug 4 '12 at 11:09
add comment

Your Answer


