help-emacs-windows
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[h-e-w] eval-after-load vs clearcase


From: Richard Y. Kim
Subject: [h-e-w] eval-after-load vs clearcase
Date: Mon, 8 Apr 2002 13:10:30 -0700

The problem is caused by clearcase-viewroot-relative-file-name-handler
(or one of the other handlers) which is added to
file-name-handler-alist by clearcase-integrate command.

This seems to be a problem in emacs itself, not a clearcase.el bug.

I was going to try to debug the problem and submit a patch.
I just never got around to it.  I believe the problem is somewhere in
emacs-21.1/src/fileio.c in one of the sections fenced with DOS_NT
macro. I verified that this problem does not exist on GNU/Linux. It is
a w32 specific problem.

I wrote up the following a while ago to submit to gnu.org as an emacs bug,
but never got around to it.
If someone else gets around to fixing this bug, that would be great.


;; First the summary.  Using GNU/Emacs 21.1, adding a handler to
;; file-name-handler-alist breaks eval-after-load, because
;; load-history contains fullpath names rather than simple names.  
;; I observed this problem on w2k, but not on Debian GNU/Linux.
;; Details follow.

;; Initialize 'foo' to `nil'.
(setq foo nil)

;; Do eval-after-load so that when 'bookmark' is loaded,
;; foo will be set to `t'.
(eval-after-load "bookmark" '(progn (setq foo t)))

(load-library "bookmark")

;; Now the value of foo is `t' as it should be.

;; Add dummy-file-name-handler do-nothing handler to file-name-handler-alist.
;; This should be no-op since it does not do anything other than to call
;; the original operation.
;; Note that this handler follows the example shown in the info node
;; "(elisp)Magic File Names" verbatim.
(defun dummy-file-name-handler (operation &rest args)
  (let ((inhibit-file-name-handlers
         (cons 'dummy-file-name-handler
               inhibit-file-name-handlers))
        (inhibit-file-name-operation operation))
    (apply operation args)))

(setq file-name-handler-alist '((".*" . dummy-file-name-handler)))

;; Reset foo to `nil'.
(setq foo nil)

;; Reload bookmark.
(load-library "bookmark")

;; foo is `nil' even after a load-library call!
;; This is because load-history now has fullpath for bookmark.elc.
;; Take a look at (car load-history).

;; Wipe out all entries in file-name-handler-alist.
(setq file-name-handler-alist nil)

;; Reset foo
(setq foo nil)

(load-library "bookmark")

;; foo is `t' as it should be after
;; the entry in file-name-handler-alist was removed.


>>>>> "SL" == Stephen Leake <address@hidden> writes:
    SL> 
    SL> I'm using Gnu Emacs 21.2, Windows NT 4.0.
    SL> I've started using Clearcase, and the apparently excellent
    SL> clearcase.el from http://www.ultranet.com/~esler/ccase-mode/.
    SL> 
    SL> I'm getting a strange interaction with my eval-after-load settup.
    SL> 
    SL> I use eval-after-load to set my keys for cc-mode:
    SL> 
    SL> (eval-after-load "cc-mode"
    SL>   '(progn
    SL>      (c-initialize-cc-mode)
    SL>      (load "c-mode-keys")
    SL>      (load "c++-mode-keys")
    SL>      (load "java-mode-keys")))
    SL> 
    SL> If I don't load clearcase.el, here's the load sequence I get when I do
    SL> M-x load-library cc-mode:
    SL> 
    SL> Loading cc-mode...
    SL> Loading image...done
    SL> Loading c-mode-keys (source)...done
    SL> Loading c++-mode-keys (source)...done
    SL> Loading java-mode-keys (source)...done
    SL> Loading cc-mode...done
    SL> 
    SL> However, if I load clearcase first, I get:
    SL> 
    SL> Loading clearcase.el (source)...done
    SL> Loading e:/Gnu/Emacs/emacs-21.2/lisp/progmodes/cc-mode.elc...
    SL> Loading e:/Gnu/Emacs/emacs-21.2/lisp/image.elc...done
    SL> Loading e:/Gnu/Emacs/emacs-21.2/lisp/progmodes/cc-mode.elc...done
    SL> 
    SL> I have not spent much time poking around in clearcase.el, but there
    SL> isn't anything obvious (ie, it doesn't reset the eval-after-load for
    SL> cc-mode; it doesn't even mention cc-mode).
    SL> 
    SL> I'm hoping someone has seen similar behavior elsewhere, and can give
    SL> me a clue what to look for.
    SL> 
    SL> Why does the 'loading' message change? does this mean 'cc-mode'
    SL> somehow got loaded by clearcase without processing the
    SL> after-load-alist? How can that happen?
    SL> 
    SL> -- 
    SL> -- Stephe
    SL> 
    SL> 
    SL> 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]