Emacs elisp rozwija nazwę pliku zachowanie na windows

Question

Napotkałem dziwne zachowanie funkcji expand-file-name w systemie Windows podczas instalacji ostatniego cedetu za pomocą el-get. Problem związany jest z generowaniem autoload.

autoload.el na ostatnich emacs 24.01.50 zawiera następującą funkcję:

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

w moim przypadku generowanego-autoload-plik jest:

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

jak mam $ HOME $ środowisko zmienna wskazuje na C:/home/ngulyamov. W tym przypadku funkcja zwraca powyżej:

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

ze względu na źródło-katalog zawiera:

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

Jak widać zmienia literę dysku z C: D :. Jednocześnie na emacs 23,3 ta funkcja zwraca naczepa poprawną wartość jako źródłowego katalogu zawiera wartość:

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

Według poszerzyć-file-name opis funkcji:

(poszerzyć-File- name NAZWA & opcjonalnie DEFAULT-DIRECTORY)

Konwertuj nazwę pliku NAZWĘ na absolutną i kanonizuj. Drugi arg DEFAULT-DIRECTORY jest katalogiem, od którego zaczyna się, jeśli NAZWA jest względna (nie zaczyna się od ukośnika lub tyldy); jeśli DEFAULT-DIRECTORY jest zerowe lub brakuje, używana jest wartość bieżącego bufora `default-directory '.

Ścieżki w systemie Windows nigdy nie zaczynają się od slasha ani tyldy.

Teraz moje pytania: 1. Czy zachowanie funkcji nazwy pliku rozszerzającego jest poprawne w systemie Windows? 2. Dlaczego katalog źródłowy zawiera wartość ścieżek programistów?

Czy możemy uznać rozszerzenie pliku nazwa za buggy w systemie Windows? Lub jest po prostu błędnie używane w autoload.el?

Z góry dziękuję.

Answer 1

W końcu znalazłem przyczynę. Problem pochodzi z Makefile z cedetu, który używa funkcji $ (abspath) make 3.8. Wersja cygwin make w tym przypadku zwraca ścieżkę do systemu UNIX, tzn./Home/ngulyamov/... która następnie zastępuje katalog główny katalogu źródłowego w autoload przez d:/home/ngulyamov/.... Wersja programu GnuWin32 działa poprawnie, ale przez dziwnego powodu mam następujący problem:

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 

tak brudne poprawka jest określającą źródło-katalog w autoload.el sama lubię:

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

Zresztą dlaczego source-katalog jest skierowaną do ścieżka komputera programisty pozostaje otwarta.