Jestem początkującym w Emacsie (używam go od około 2 tygodni i kocham). Gdy aktualizuję i rozszerzam mój ~/.emacs.d/init.elplik, rzeczy, które tam piszę, zależą od niektórych pakietów, które zainstalowałem z MELPA M-x package-install, od .elplików, które sam napisałem itp.

Moje pytanie brzmi: czy powinienem w przyszłości na przykład przełączać komputery, jaki jest najlepszy sposób, aby bezproblemowo uzyskać takie samo dokładne środowisko Emacs na nowym komputerze, jak teraz?

Prawidłowym rozwiązaniem jest użycie straight.elmenedżera pakietów, który napisałem w celu rozwiązania tego problemu. Więcej informacji na ten temat można znaleźć w innej odpowiedzi na to pytanie .

Ta odpowiedź, napisana kilka miesięcy przed rozpoczęciem pracy straight.el, poprzednio opisywała zdecydowanie gorszy sposób osiągnięcia częściowego rozwiązania. Podejście to opisano krótko poniżej; Już go nie polecam.

Nawet jeśli nie chcesz używać straight.el, powinieneś przynajmniej adoptować use-package. (Nie chodzi o to, że te dwa wykluczają się wzajemnie - uważam, że najczystsza konfiguracja pochodzi z użycia obu).

Zacznij od zdefiniowania listy pakietów w pliku inicjującym:

(defvar my-packages
        '(
          aggressive-indent
          avy
           .
           .
           .
          projectile
          undo-tree
          )
  "List of packages to be installed at Emacs startup.")

Następnie zainstaluj je automatycznie:

(require 'cl-lib)
(package-initialize)
(unless (cl-every #'package-installed-p my-packages)
  (dolist (package my-packages)
    (unless (package-installed-p package)
      (package-install package))))

Jeśli init.elplik będzie pod kontrolą wersji, synchronizacja go z innym komputerem spowoduje automatyczne zainstalowanie pakietów. Oczywiście zainstalowane wersje będą zupełnie inne i nie można oczekiwać, że konfiguracja będzie działać od razu po wyjęciu z pudełka. Jest to podstawowa wada package.eli jeden z powodów, dla których takie podejście jest złe. Zobacz jeszcze raz straight.el. Zauważ też, że powyższy kod oddziela listę pakietów od konfiguracji dla tych pakietów, co utrudnia śledzenie rzeczy w pliku inicjującym. To kolejna poważna wada. Zobacz jeszcze raz use-package.

Jeśli używasz pakietu use , możesz przenosić ten plik z komputera na komputer, a gdy Emacs się uruchomi, dopóki masz dostęp do Internetu, pobierze pakiety i je skonfiguruje.

Najpierw skonfiguruj bibliotekę pakietów:

(require 'package)
(add-to-list 'package-archives
             '("melpa" . "https://melpa.org/packages/") t)
(package-initialize)

A następnie bootstrap use-package:

(unless (package-installed-p 'use-package)
  (package-refresh-contents)
  (package-install 'use-package))

(eval-when-compile (require 'use-package))

Teraz zamiast konfigurować Emacsa i zakładać, że pakiety są instalowane, użyj use-packagezarówno do ich instalacji, jak i konfiguracji. Na przykład dla niektórych ustawień mojego steru:

(use-package helm
  :ensure t
  :bind (("M-x" . helm-M-x)
         ("M-y" . helm-show-kill-ring)
         ("C-x C-f" . helm-find-files)
         ("M-s o" . helm-occur))

  :config
  (helm-mode 1)
  (setq helm-echo-input-in-header-line t))

Zarządzanie pakietami nowej generacji za pomocą straight.el

Po długiej i frustrującej walce o użycie package.el+ Quelpa do zarządzania moimi pakietami, ugryzłem kulę i napisałem własnego menedżera pakietów . Jest on przeznaczony do całkowitego zastąpienia package.elzapewniając doświadczenie zarządzania pakietami, który jest lepszy w prawie każdym względem.

Możesz przeczytać bardzo obszerną dokumentację, aby dowiedzieć się o wszystkich jej funkcjach, ale najbardziej odpowiednia dla tego pytania jest straight.elkoncentracja na doskonałej odtwarzalności . Oznacza to, że nie powinno mieć znaczenia, czy uruchamiasz Emacsa normalnie, czy uruchamiasz go na nowej maszynie, a wszelkie lokalne zmiany są kontrolowane przez wersję i można je przywrócić do stanu kanonicznego. W praktyce osiąga się to poprzez (1) klonowanie pakietów jako repozytoria Git oraz zapewnienie automatycznych narzędzi do zarządzania ich stanem; (2) wykorzystanie pliku init jako jedynego źródła prawdy dla stanu zarządzania pakietami, bez żadnych zmiennych danych przechowywanych gdzie indziej; oraz (3) użycie opcjonalnych plików blokujących wersji w celu określenia dokładnych wersji Git każdego pakietu, a także repozytoriów receptur istraight.el samo.

Aby rozpocząć, włóż fragment kodu ładującego , który zostanie zainstalowany i aktywowany straight.el. Następnie, aby upewnić się, że pakiet jest zainstalowany, po prostu umieść wywołanie straight-use-packagew pliku init:

(straight-use-package 'projectile)

Tak, to takie proste. Żadnego zajmowania się package-refresh-contentsżadnym z tych śmieci. Jeśli usuniesz ten formularz ze swojego pliku inicjującego i zrestartujesz Emacsa, pocisk nie będzie już ładowany (w przeciwieństwie do in package.el). Oznacza to, że nie musisz się martwić, że Twoja konfiguracja w jakiś sposób nie działa na nowym komputerze, ponieważ przypadkowo polegałeś na niezadeklarowanych pakietach.

Możesz instalować pakiety gdziekolwiek i kiedykolwiek chcesz, w całym pliku init (nie musisz deklarować ich listy w jednym punkcie). Oczywiście, że możesz po prostu zrobić

(dolist (package '(ace-jump-mode ... zzz-to-char)) (straight-use-package package))

jeśli wolisz listę. Polecam jednak użyć use-packagedo zarządzania konfiguracją pakietu. Najpierw musisz go zainstalować:

(straight-use-package 'use-package)

Następnie, ponieważ straight.elma wbudowaną integrację z use-package, następujące „po prostu działa”:

(use-package projectile
  :straight t
  :init (projectile-mode 1))

Po napisaniu pliku init do zainstalowania potrzebnych pakietów, uruchom, M-x straight-freeze-versionsaby zapisać plik blokady wersji ~/.emacs.d/straight/versions/default.el. Powinieneś zachować ten plik pod kontrolą wersji, ponieważ pozwoli straight.elon sprawdzić poprawne wersje wszystkich twoich pakietów, kiedy po raz pierwszy uruchomisz Emacsa na nowej maszynie. (Można ręcznie przywrócić wersje określone w pliku blokującym za pomocą M-x straight-thaw-versions.)

Aby wesprzeć ideę lokalnych plików dotfile, o których wspomniałem w mojej innej odpowiedzi , straight.eloferuje system profili . Nadal zalecam używanie dowiązań symbolicznych do plików dot (w tym przypadku, init.ellokalnego pliku init, jeśli dotyczy, i pliku blokady wersji, jeśli chcesz go użyć).

Jeśli zastanawiasz się, jak straight.elwypada w porównaniu z innymi menedżerami pakietów, sprawdź obszerną sekcję porównań . Ale jest też o wiele więcej dokumentacji na wszystko inne .

Możesz użyć beczki do zarządzania swoimi paczkami. Użyj git / github do kontroli źródła i zsynchronizuj pliki dot emacsa.