ms> `locate-file' has at least one other bug connected with ms> absolute file names. Unfortunately, there's quite a bit of ms> code which expects ms> (load-library "mule/foo.el") ms> to search the load-path. ms> So I suggest fixing ./ with locate-file, but leaving the other ms> case alone. I'll do it along with the other bug, if you guys ms> want me to. What do you mean by "fixing"? I know what _I_ like, but treating "./bar" as relative to `default-directory' but "foo/bar" as relative to the path is pretty inconsistent. It's pretty clear that my intuition that "./bar" should be absolute is wrong as a matter of Unix usage; there are specific references "relative paths" that use "./bar" as an example in lread.c! I think that the right way to "fix" this is to document it. :-( What "other bug" are you talking about? lread.c mentions several possible sources of lossage; do you mean l. 751 /* #### Disgusting kludge */ /* Run any load-hooks for this file. */ /* #### An even more disgusting kludge. There is horrible code */ /* that is relying on the fact that dumped lisp files are found */ /* via `load-path' search. */ or l. 1066 /* If there are non-absolute elts in PATH (eg ".") */ /* Of course, this could conceivably lose if luser sets default-directory to be something non-absolute ... */ or l. 3092 /* kludge: locate-file does not work for a null load-path, even if the file name is absolute. */ or something else? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."