re:anybody got efs working under lemacs-19.10 b24?

hamish (hamish@bnr.ca)
Tue, 17 May 1994 13:51:00 -0400 

>>>>> On Tue May 17 12:43:00 1994,
>>>>> Jeff wrote:

Jeff> The main error I see is in indirect_function, which is giving me
Jeff> the error "symbols function definition is void" for
Jeff> efs-file-name-handler.  In fact, it seems like many of the
Jeff> defuns in efs.el disappear.

Oh yeah... I fixed that one.  The problem is that efs adds functions
to the file-name-handler-alist before it has defined those functions.

After file-name-handler-alist has been loaded, but before
efs-file-name-handler has been defined, efs tries to load some source
files (i.e. it tries to load efs-netrc after loading efs-ovwrt).

In lemacs-19.10 b23, "load" seems to consult the
file-name-handler-alist.  It finds efs-file-name-handler on the alist,
but the function isn't defined yet.

The solution I used was to move the loading of efs-ovwrt to after all
the other stuff had been loaded.  Patch enclosed at end.

I still have problems.  I think that all calls to
find-file-name-handler are supposed to pass the operation as the
second argument now.

Here is the documentation for find-file-name-handler from b24:

find-file-name-handler: (filename &optional operation)
  -- a built-in function.
Return FILENAME's handler function for OPERATION, if it has one.
Otherwise, return nil.
A file name is handled if one of the regular expressions in
`file-name-handler-alist' matches it.

If OPERATION equals `inhibit-file-name-operation', then we ignore
any handlers that are members of `inhibit-file-name-handlers',
but we still do run any other handlers.  This lets handlers
use the standard functions without calling themselves recursively.

Jeff> There is a also a separate problem with efs-auto that seems to
Jeff> cause infinite loading of efs.el, most likely to get the
Jeff> definition of efs-file-name-handler.  This leads to max lisp
Jeff> depth exceeded.

I don't use efs-auto.  I just use "(require 'efs)".  I suspect that
efs should never add its functions to the file-name-handler-alist
unless the real definitions of its functions (efs-file-name-handler
etc.) are loaded already.  

I think that autoloading this is too tricky anyway.  do_autoload (in
lread.c in lemacs) calls Fload.  Fload checks the
file-name-handler-alist.

file-name-handler-alist should not be set unless the functions called
from it are loaded and ready to their thing.

I suppose that what you could have in file-name-handler-alist are
references to some _completely_ defined functions which inhibit the
application file-name-handler-alist, and load the rest of efs.

I don't know why it worked before and not now, though...  I don't
think that lemacs has changed *that* much.

--snip-----------------------------------------------------------
diff -cr --exclude=*.elc efs-1.6/efs.el efs/efs.el
*** efs-1.6/efs.el	Mon Feb 21 12:13:36 1994
--- efs/efs.el	Sat May 14 17:42:42 1994
***************
*** 903,909 ****
  (require 'backquote)
  (require 'comint)
  (require 'efs-defun)
- (require 'efs-ovwrt)
  (require 'efs-netrc)
  (require 'efs-cu)
  (autoload 'efs-report-bug "efs-report" "Submit a bug report for efs." t)
--- 903,908 ----
***************
*** 912,917 ****
--- 911,917 ----
  	  "Login to the gateway machine and fire up an FTP client.")
  (autoload 'efs-insert-directory "efs-dired" "Insert a directory listing.")
  (autoload 'efs-set-mdtm-of "efs-cp-p")
+ (require 'efs-ovwrt)
  
  
  ;;;; ============================================================