2012-05-10 4 views
5

Ich stieß auf seltsames Verhalten der Funktion expand-file-name auf Windows während der Installation des letzten Cedet mit el-get. Das Problem bezieht sich auf die Generierung von Autoloads.Emacs elisp Expansion-Dateiname Verhalten auf Windows

Die autoload.el letzter Emacs 24.1.50 die folgende Funktion enthält:

(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)))) 

In meinem Fall erzeugt-Autoload-Datei ist:

"/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/srecode/loaddefs.el" 

wie ich $ Umwelt HOME $ Variable zeigt auf C:/home/ngulyamov. In diesem Fall oben Funktion gibt:

"d:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/srecode/loaddefs.el" 

aufgrund source-Verzeichnis enthält:

"d:/devel/emacs/emacs-bzr/trunk_jenkins/". 

Wie Sie es Laufwerksbuchstaben aus C ändert sich sehen: auf D :. Zur gleichen Zeit auf Emacs 23.3 diese Funktion halb korrekten Wert als Quelle-Verzeichnis zurückgibt enthält Wert:

"c:/Users/Sean/Downloads/emacs-23.3/". 

Nach Funktionsbeschreibung erweitern-file-name:

(expand-File- Name NAME & optional DEFAULT-DIRECTORY)

Konvertieren Sie den Dateinamen NAME in absolute und kanalisieren Sie ihn. Zweites Argument DEFAULT-DIRECTORY ist das Verzeichnis, mit dem zu beginnen ist, wenn NAME relativ ist (beginnt nicht mit Schrägstrich oder Tilde); Wenn DEFAULT-DIRECTORY null oder nicht vorhanden ist, wird der aktuelle Pufferwert von `default-directory 'verwendet.

Die Pfade unter Windows beginnen nie mit Schrägstrich oder Tilde.

Nun meine Fragen: 1. Funktioniert Expand-File-Name Funktion Verhalten auf Windows? 2. Warum Quellverzeichnis enthält Wert der Entwickler Pfade?

Könnten wir expand-file-name als Buggy auf Windows betrachten? Oder es wird einfach falsch in autoload.el verwendet?

Vielen Dank im Voraus.

+0

Wurde der erste Pfad mit 'c:' beginnen? – phils

+0

@phils Hallo, nein, es nicht mit C startet: aber alles funktioniert ziemlich gut: 'C: \ home \ ngulyamov> set HOME HOME = C: \ home \ ngulyamov C: \ home \ ngulyamov> env | grep HOME HOME =/home/ngulyamov C: \ home \ ngulyamov> ls/home/ngulyamov ... fileliste .... ' –

+0

Dies ist offensichtlich eine Art von Windows-Shell, die ich noch nie zuvor gesehen habe, wenn es Vorwärts Schrägstriche verwendet, und akzeptiert 'ls' als ein Befehl. (Ist das Windows 7?) – phils

Antwort

2

Endlich habe ich den Grund herausgefunden. Das Problem kommt von Makefile von cedet, das $ (abspath) Funktionalität von make 3.8 verwendet. Die cygwin-Version von make gibt in diesem Fall UNIX-Pfadpfad zurück, dh/home/ngulyamov/..., der dann durch das Quellverzeichnis root in autoload durch d:/home/ngulyamov/... ersetzt. Die GnuWin32-Version von make ich habe folgendes Problem richtig, aber von seltsamen Grund funktioniert:

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 

So schmutzig fix ist die Angabe Quelle-Verzeichnis in autoload.el selbst mag:

(setq-default source-directory "C:/home/ngulyamov/.emacs.d/") 

wie auch immer, warum Source-Verzeichnis verweist auf Der Computerpfad des Entwicklers ist noch offen.