From xemacs-m  Thu Feb 13 17:55:36 1997
Received: from cs.sunysb.edu (sbcs.sunysb.edu [130.245.1.15])
	by xemacs.org (8.8.5/8.8.5) with SMTP id RAA08503
	for <xemacs-beta@xemacs.org>; Thu, 13 Feb 1997 17:55:34 -0600 (CST)
Received: from sbkifer.cs.sunysb.edu (sbkifer.cs.sunysb.edu [130.245.1.35]) by cs.sunysb.edu (8.6.12/8.6.9) with SMTP id TAA23848 for <xemacs-beta@xemacs.org>; Thu, 13 Feb 1997 19:04:23 -0500
Message-Id: <199702140004.TAA23848@cs.sunysb.edu>
X-Authentication-Warning: sbcs.cs.sunysb.edu: Host sbkifer.cs.sunysb.edu didn't use HELO protocol
From: kifer@CS.SunySB.EDU (Michael Kifer)
To: xemacs-beta@xemacs.org
Subject: efs broken in 20.0
Date: Thu, 13 Feb 1997 18:52:58 -0500
Sender: kifer@CS.SunySB.EDU



Something fishy is going on when efs-1.15 interacts with find-file
in XEmacs20.0 compiled --with-mule.

First, (require 'efs) knocks off the optional arg from find-file and relatives.
This is because default-dir.el checks for (boundp 'MULE), but this var is
not defined.

Second, the func efs-overwrite-fn in efs-ovwrt.el appears to interact
poorly with advice.el. 

If you first load (require 'efs) and then do:

(defadvice find-file (before vip-add-suffix-advice activate)
  "Use `read-file-name' for reading arguments."
  (interactive (list (read-file-name "Find file: " nil default-directory))))

then everything is fine. But if you first advise find-file and *then* load
efs, find-file breaks, as you start geting errors about the wrong number of
args. 

Note: it doesn't help if I advise find-file with two arguments, to match
the definition of 20.0.


	--michael  

