Re: problem with latest ediff and clearcase mode?

-- Charles Hines <hines(a)gderome.com&gt; spake thusly: <snip> I'm having similar problems with ediff and dired (and I'm _amazed_ that no-one else is seeing this). Specifically, whenever a dired buffer is opened, it installs a handler: (defun dired-check-file-name-handler-alist () ;; Verify that dired is installed as the first item in the alist (and dired-refresh-automatically (or (eq (cdr (car file-name-handler-alist)) 'dired-handler-fn) (setq file-name-handler-alist (cons '("." . dired-handler-fn) (dired-remove-from-file-name-handler-alist)))))) Since the regexp for this handler is ".", it applies to all files. When ediff is operating on non-files, it calls ediff-file-remote-p and aborts if it returns true. ediff-file-remote-p always returns true if a dired buffer is open, because find-file-name-handler always returns 'dired-handler-fn. I just researched this a bit more, and it looks like the problem is that the only thing find-file-name-handler pays attention to for the second parameter is whether it's set to 'inhibit-file-name-operation. What should actually be happening is the following: ;; file-local-copy returns nil if the file is already local (defun ediff-file-remote-p (file-name) (file-local-copy file-name)) The only problem with this is that emacs will then try to access that file remotely if it is indeed a remote file. However, since ediff already uses (ediff-find-file ...) to load remote files, anything getting passed to ediff-file-remote-p should already be local (in which case, why is this even being used?). Just in case, it might be best to do: (defun ediff-file-remote-p (file-name) (let ((tmpfile (file-local-copy file-name))) (if tmpfile (delete-file tmpfile)) tmpfile)) Comments, Michael? Could you make this (or some similar) change to ediff-init.el?