2011-01-05 17 views
9

Emacs ma to na pozór bardzo ładne narzędzie do budowania plików autoload opartych na magicznych komentarzach kodu źródłowego ("automatyczne ciasteczka") w postaci ;;;###autoload, które są umieszczane na liniach bezpośrednio nad każdą definicją do automatycznego ładowania; patrz (elisp)Autoload.Konserwacja plików autoload Emacsa dla elisp użytkownika zainstalowany?

Wydaje się, że jest to idealne narzędzie do utrzymywania autoloads dla tych małych, jednoplikowych pakietów, których użytkownicy Emacs nieuchronnie będą musieli zainstalować w swoich profilach. Jest tylko jeden mały problem: ten obiekt (w GNU Emacs, tak czy inaczej) wydaje się prawie w całości skupiać się na generowaniu pliku loaddefs.el dla samego Emacsa, z bardzo małą (jeśli w ogóle) koncesją na inne zastosowania.

To nie powstrzymuje dużych pakietów od korzystania z maszyn autoloads.el do budowania własnych plików autoload, ale te, które widziałem mają dość dość owłosiony kod poświęcony, aby zrobić to, co jest potrzebne, choć niektóre owłosienie może być spowodowane rozbieżnościami GNU Emacs/XEmacs.

(Wydaje mi się, że XEmacs jest nieco lepszy na tym froncie, prawdopodobnie przynajmniej z powodu faktu, że jego oficjalny system pakietów używa tej maszyny do tworzenia osobnych plików autoload dla każdego pakietu.Najpowiedniej, włączenie GNU Emacs do ELPA system pakietów, który również korzysta z tej maszyny, prowadzi do podobnych ulepszeń na ich stronie)

Więc moje pytanie do was jest.

Jak należy zachować plik autoload dla wszystkich .el plików w katalogu , zakładając, że mają już wszystkie niezbędne komentarze ;;;###autoload (autoload cookies)?

[Hmm. Cytaty blokowe wyglądają dużo coolor na tex.SE ...]

Obecnie używam GNU Emacs 23.2.1, choć im dalej odpowiedź się powtarza, tym lepiej. (W tym przypadku byłoby miło, gdyby działało również z XEmacs.)

Jestem w systemie Windows, ale mam zainstalowany program MSYS obok Emacsa, więc skrypty sh/bash prawdopodobnie będą w porządku, o ile nie będą Nazwijcie coś strasznie egzotycznego.

[Nie jestem całkowicie pewny, że to nie należy do administratora, a nie do SO. Jeśli istnieje już pakiet, który może sobie z tym poradzić przy niewielkiej ilości konfiguracji, prawdopodobnie tak; z drugiej strony, jeśli (jak podejrzewam) istnieją tylko surowe fragmenty kodu, które mogą wymagać dużej liczby bezpośrednich zmian, myślę, że prawdopodobnie należy tutaj SO.]

+0

Hm, wydaje się, że ktoś inny niż ja faworyzował to, ale nie wzbraniał się: 2 użytkowników dodało do niego (jeden z nich to ja, myślę), ale nie ma żadnych głosów. Zastanawiam się, dlaczego to jest - zapomnienie? – SamB

Odpowiedz

0

W 2017 r. Nie trzeba go utrzymywać samodzielnie. Zamiast tego możesz użyć nowoczesnego menedżera pakietów, takiego jak straight.el, który został specjalnie zaprojektowany, aby zająć się tym (jak również wieloma innymi rzeczami) dla Ciebie.

Można użyć package.el zamiast straight.el, ale package.el ma kilka poważnych problemów, a szczególnie istotne jest to, że jest to bardzo niewygodne, aby uzyskać package.el załadować lokalnego pakietu Pisałeś siebie, aw szczególności package.el ma absolutnie brak wsparcia dla dokonywania modyfikacji pakietu po jego zainstalowaniu.

Można również użyć innych menedżerów pakietów. Napisałem obszerną sekcję comparing straight.el to other package managers.

+0

"To bardzo niezręczne, aby pakiet package.el ładował lokalny pakiet, który sam napisałeś" ... erm, nie, nie jest; w rzeczywistości jest to niezwykle łatwe: 'Mx pakiet-install-file' – phils

+0

@phils Następnie musisz ponownie uruchomić to polecenie za każdym razem, gdy dokonasz modyfikacji pliku, a ponadto musisz przeskakiwać przez obręcze podczas używania' Mx find- funkcja i przyjaciele, aby upewnić się, że edytujesz prawdziwy plik, a nie kopię utworzoną przez pakiet 'package.el'. Nie nazywam to tak łatwo. –