在使用el-get安装最后一个ceet的过程中，我在Windows上遇到了expand-file-name函数的奇怪行为。问题与自动加载的生成有关。
最后emacs 24.1.50上的autoload.el包含以下功能:
(defun autoload-generated-file ()
(expand-file-name generated-autoload-file
;; File-local settings of generated-autoload-file should
;; be interpreted relative to the file's location,
;; of course.
(if (not (local-variable-p 'generated-autoload-file))
(expand-file-name "lisp" source-directory))))
在我的情况下，generate-autoload-file是:
"/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/srecode/loaddefs.el"
因为我有$ HOME $环境变量指向C:/home/ngulyamov。在这种情况下，上面的函数返回:
"d:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/srecode/loaddefs.el"
由于源目录包含:
"d:/devel/emacs/emacs-bzr/trunk_jenkins/".
如您所见，它将驱动器号从C:更改为D:。
同时在emacs 23.3上，此函数返回半正确的值，因为源目录包含值:
"c:/Users/Sean/Downloads/emacs-23.3/".
根据扩展文件名功能描述:
(扩展名NAME和可选的DEFAULT-DIRECTORY)
将文件名NAME转换为绝对文件，并将其规范化。
如果NAME是相对的，第二个参数DEFAULT-DIRECTORY是要开始的目录
(不以斜杠或波浪号开头)；如果DEFAULT-DIRECTORY为零或丢失，
使用当前缓冲区的“默认目录”值。
Windows上的路径从不以斜杠或波浪号开头。
现在我的问题是:
1.在Windows上，expand-file-name函数的行为是否正确？
2.为什么源目录包含开发人员路径的值(value)？
我们可以在Windows上将expand-file-name视为 buggy 吗？还是在autoload.el中错误地使用了它？
先感谢您。
最佳答案
最后我弄清楚了原因。问题来自cedet的Makefile，该文件使用make 3.8的$(abspath)功能。在这种情况下，make的cygwin版本返回UNIX路径，即/home/ngulyamov/...，然后在自动加载时将源目录根目录替换为d:/home/ngulyamov/...。make的GnuWin32版本可以正常工作，但是由于奇怪的原因，我遇到以下问题:
C:\home\ngulyamov\.emacs.d\el-get\cedet>\gnuwin32\bin\make all
Removing loaddefs.el files from subprojects.
Generating autoloads.
make[1]: Entering directory `C:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet'
> autoloads
Wrote C:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/loaddefs.el
Loading vc-bzr...
Generating autoloads for C:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/cedet-android.el...
Memory exhausted--use C-x s then exit and restart Emacs
make[1]: *** [autoloads] Error 127
因此，肮脏的修补程序是在autoload.el本身中指定源目录，例如:
(setq-default source-directory "C:/home/ngulyamov/.emacs.d/")
无论如何，为什么源目录指向开发人员的计算机路径仍处于打开状态。
关于Windows上的Emacs elisp扩展文件名行为，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/10535529/