5:04 p.m.
Howdy all.
I noticed that using the latest Ediff package (from the current SUMO, in
conjunction with 21.1.14) fails to work if clearcase mode has been loaded.
Using the elisp debugger I've traced the problem to changes in
ediff-file-remote-p which now calls:
(find-file-name-handler file-name 'file-local-copy)
instead of it's previous method of checking:
(car (cond ((featurep 'efs-auto) (efs-ftp-path file-name))
((fboundp 'file-remote-p) (file-remote-p file-name))
(t (require 'ange-ftp)
;; Can happen only in Emacs, since XEmacs has file-remote-p
(ange-ftp-ftp-name file-name))))
and the latest clearcase.el available from:
http://www.ultranet.com/~esler/ccase-mode/
sets a find-file-name-handler:
;; This handler ensures that VC doesn't attempt to operate inside the MVFS.
;; This stops it from futile searches for RCS directories and the like inside.
;; It prevents a certain amount of clutter in the MVFS' noent-cache.
;;
(defun clearcase-suppress-vc-within-mvfs-file-name-handler (operation &rest
args)
(clearcase-when-debugging
(if (fboundp 'clearcase-utl-syslog)
(clearcase-utl-syslog "*clearcase-fh-trace*"
(cons
"clearcase-suppress-vc-within-mvfs-file-name-handler:"
(cons operation args)))))
;; Inhibit recursion:
;;
(let ((inhibit-file-name-handlers
(cons 'clearcase-suppress-vc-within-mvfs-file-name-handler
(and (eq inhibit-file-name-operation operation)
inhibit-file-name-handlers)))
(inhibit-file-name-operation operation))
(cond
((and (eq operation 'vc-registered)
(clearcase-file-would-be-in-view-p (car args)))
nil)
(t
(apply operation args)))))
and if I set the variable that keeps this handler from being installed, ediff
works fine. But if this handler gets installed, ediff won't work on ANY 2
files (not just files residing in the clearcase filesystem), failing with a
"Can't diff remote files:" message.
So I'm wondering where the problem actually lies, in the handler that
clearcase.el registers or in the ediff definition of ediff-file-remote-p? I
felt that someone else on the list would be much better qualified to answer
that question than myself (I have no clue).
Thanks,
Chuck
--
Charles K. Hines <ckh(a)requesttech.com> <hines(a)gderome.com>
Principal Scientist at ReQuest Technologies Inc (http://www.ReQuestTech.com/)
Martial Arts Instructor [Modern Arnis and Balintawak Escrima]
"Go back to sleep, Chuck. You're just havin' a nightmare
-- of course, we ARE still in Hell." (Gary Larson)
11:49 p.m.
Charles Hines writes:
I noticed that using the latest Ediff package (from the current SUMO,
in
conjunction with 21.1.14) fails to work if clearcase mode has been
loaded.
<snip>
and if I set the variable that keeps this handler from being
installed, ediff
works fine. But if this handler gets installed, ediff won't work on ANY 2
files (not just files residing in the clearcase filesystem), failing with a
"Can't diff remote files:" message.
As an added datapoint, I was getting the same problem today with
hide-copyleft mode on.
Sean
3:06 a.m.
-- Charles Hines <hines(a)gderome.com> spake thusly:
I noticed that using the latest Ediff package (from the current
SUMO,
in conjunction with 21.1.14) fails to work if clearcase mode has been
loaded. Using the elisp debugger I've traced the problem to changes in
ediff-file-remote-p which now calls:
(find-file-name-handler file-name 'file-local-copy)
instead of it's previous method of checking:
(car (cond ((featurep 'efs-auto) (efs-ftp-path file-name))
((fboundp 'file-remote-p) (file-remote-p file-name))
(t (require 'ange-ftp)
;; Can happen only in Emacs, since XEmacs has file-remote-p
(ange-ftp-ftp-name file-name))))
and the latest clearcase.el available from:
http://www.ultranet.com/~esler/ccase-mode/
sets a find-file-name-handler:
<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?
6:31 p.m.
What is exactly happening? Are you getting the error "Can't diff remote
files"?
If so, I've fixed this recently and will commit the change this weekend.
Meanwhile, you can just remove the cases that produce this msg from
ediff-diff.el.
Or is it a different problem?
--michael
> I noticed that using the latest Ediff package (from the current SUMO,
> in conjunction with 21.1.14) fails to work if clearcase mode has been
> loaded. Using the elisp debugger I've traced the problem to changes in
> ediff-file-remote-p which now calls:
>
> (find-file-name-handler file-name 'file-local-copy)
>
> instead of it's previous method of checking:
>
> (car (cond ((featurep 'efs-auto) (efs-ftp-path file-name))
> ((fboundp 'file-remote-p) (file-remote-p file-name))
> (t (require 'ange-ftp)
> ;; Can happen only in Emacs, since XEmacs has file-remote-p
> (ange-ftp-ftp-name file-name))))
>
> and the latest clearcase.el available from:
>
> http://www.ultranet.com/~esler/ccase-mode/
>
> sets a find-file-name-handler:
<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?
--==========1753282363==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6g17EU7AqV+YCBioRAnYIAKCbDZNe+t6KcjSXEOWsxl4L3CXczwCgtbzF
snsdSM/ihz4zsnZAiZnD59s=
=KG3O
-----END PGP SIGNATURE-----
--==========1753282363==========--
12:04 a.m.
-- Michael Kifer <kifer(a)cs.sunysb.edu> spake thusly:
What is exactly happening? Are you getting the error "Can't
diff
remote files"? If so, I've fixed this recently and will commit the
change this weekend. Meanwhile, you can just remove the cases that
produce this msg from ediff-diff.el.
Or is it a different problem?
That is exactly the error, as I think was mentioned in the original
post describing the problem. I look forward to your patch, although
I've fixed it here until then.
4:28 a.m.
>>>> "CH" == Charles Hines <of Thu, 08 Feb
2001 12:04:24 EST> writes:
CH> I noticed that using the latest Ediff package (from the current SUMO, in
CH> conjunction with 21.1.14) fails to work if clearcase mode has been loaded.
What is exactly the problem? Is it saying "Can't diff remote files".
If so, I've fixed this bug recently, but havent committed the fix yet.
I am going to do it this weekend.
Until the new package is released, you can alleviate the pain by simply
commenting out the lines that issue this error in ediff-diff.el
--michael
1:56 p.m.
>>>> "Michael" == Michael Kifer
<kifer(a)cs.sunysb.edu> writes:
>>>> "CH" == Charles Hines <of Thu, 08 Feb
2001 12:04:24 EST> writes:
CH> I noticed that using the latest Ediff package
(from the current SUMO, in
CH> conjunction with 21.1.14) fails to work if clearcase mode has been loaded.
Michael> What is exactly the problem? Is it saying "Can't diff remote
files".
Correct. It then shows 0 diffs upon entering ediff mode.
Michael> If so, I've fixed this bug recently, but havent committed the fix yet.
Michael> I am going to do it this weekend.
Cool.
Michael> Until the new package is released, you can alleviate the pain by
Michael> simply commenting out the lines that issue this error in
Michael> ediff-diff.el
Yeah, I found several ways to get around it, I just wasn't wasn't sure what
"the right one" was and if the problem was really in clearcase mode or in
ediff (seems to be the latter due to the other instances that have been
reported and the fact that you've fixed the bug already). Some variant of the
(defalias 'ediff-file-remote-p 'file-remote-p) that Adrian Aichner recommened
seemed to me to be the best for use in XEmacs, but since that's not available
in Emacs I imagine that your solution is slightly more comprehensive.
Thanks,
Chuck
--
Charles K. Hines <ckh(a)requesttech.com> <hines(a)gderome.com>
Principal Scientist at ReQuest Technologies Inc (http://www.ReQuestTech.com/)
Martial Arts Instructor [Modern Arnis and Balintawak Escrima]
"Go back to sleep, Chuck. You're just havin' a nightmare
-- of course, we ARE still in Hell." (Gary Larson)
8686
days inactive
8689
days old
6 comments
4 participants
participants (4)
-
Charles Hines -
Matt Tucker -
Michael Kifer -
Sean MacLennan