Aynı Emacs ortamını farklı bir bilgisayara nasıl alabilirim?


16

Emacs'da yeni başlayan biriyim (yaklaşık 2 hafta kullanıyorum ve sevdim). Ben güncellemek ve benim genişledikçe ~/.emacs.d/init.elkullandığımı MELPA yüklenmiş belirli paketlerin orada bağlı yazmak olduğunu, şeyleri dosyasını M-x package-installüzerine, .elben yazdım o dosyaları vb kendim

Sorum şu: Örneğin, gelecekte bilgisayarları değiştirmeli miyim, şu an sahip olduğum ile aynı Emacs ortamını sorunsuz bir şekilde elde etmenin en iyi yolu nedir?


3
init.elEtrafınızı hareket ettirebildiğiniz sürece (örneğin git kullanarak), bu yaklaşım da işe yarar (dayalı use-package): lunaryorn.com/posts/…
VanLaser

Bir yaklaşım .emacs.d dizininizi Dropbox'a koymaktır. Ben sadece aynı işletim sistemine sahip bilgisayarlarda kullandım. * Nix'in farklı lezzetleri iyi olmalıdır, ancak çok farklı işletim sistemleri çalıştıran makinelerde paylaşmaya çalışırsanız sorun yaşayabilirsiniz.
Qudit

Bu soru emacs.stackexchange.com/q/408/2710 adresine çok yakın . Farklılıkları vurgulayabilir misiniz?
Andrew Swann

Benim gibi programcı olmayan kullanıcılar için emacs yapılandırmasını ve paketlerini Google Drive'ı kullanarak üç makine (iki pencere, bir OSX) arasında senkronize etmek etkili ve güvenilir olmuştur. Bu çalışır çünkü emacs ve paketlerinin çoğu büyük ölçüde platform agnostiktir. Aynı emacs deneyiminin platformlar arası çoğaltılması, senkronize emacs paket dizinine işletim sistemine özgü yolları çözümlemek için init.el dosyasında yalnızca birkaç satır gerektirir.
Snelephant

Yapılandırmanız tüm ~/.emacs.ddizininizdir, bu nedenle makineler arasında senkronize etmeyi tercih ettiğiniz yöntemi kullanın. (örneğin bir Github deposu veya bir Dropbox klasörü veya sizin için en uygun olanı).
phils

Yanıtlar:


9

Doğru çözümü, straight.elbu sorunu çözmek için yazdığım bir paket yöneticisi kullanmaktır . Bununla ilgili daha fazla ayrıntıyı bu sorunun cevabında bulabilirsiniz .

Çalışmaya başlamadan aylar önce yazılmış olan bu cevap, daha önce straight.elkısmi bir çözüme ulaşmanın kesinlikle daha aşağı bir yolunu tanımlamıştı. Bu yaklaşım aşağıda kısaca açıklanmaktadır; Artık tavsiye etmiyorum.

Kullanmak istemeseniz bile straight.el, en azından benimsemelisiniz use-package. (İkisinin birbirini dışlamadığından değil — En temiz kurulumun her ikisini de kullanmaktan geldiğine inanıyorum.)


İnit dosyanızdaki paketlerin bir listesini tanımlayarak başlayın:

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

Ardından bunları otomatik olarak yükleyin:

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

init.elDosyanızı sürüm kontrolü altında tutarsanız, başka bir makineyle senkronize edilmesi, paketlerinizin otomatik olarak yüklenmesine neden olur. Tabii ki, yüklü sürümler tamamen farklı olacaktır ve sonuç olarak yapılandırmanızın kutudan çıkması beklenemez. Bu temel bir kusurdur package.elve bu yaklaşımın kötü olmasının nedenlerinden biridir. Tekrar bakın straight.el. Yukarıda ana hatlarıyla verilen kodun, paket listenizi bu paketler için yapılandırmanızdan ayırdığını ve init dosyanızdaki şeyleri izlemeyi zorlaştıracağını da unutmayın. Bu bir başka büyük dezavantaj. Tekrar bakın use-package.


Yazdığınız için teşekkürler! MELPA'dan indirdiğim paketler de dahil olmak üzere her şeyi Github'da barındırmayı seçersem, bu MELPA'nın paketleri yeni bilgisayarda otomatik güncelleme yeteneğini koruyacak mı?
space_voyager

1
@space_voyager Evet, her şey yine de aynı şekilde olacak. Ancak: Eğer yeni bir bilgisayara klonlamak zaman, Emacs olmaz (1) lüzum onlar sadece klonlanmış havuzda zaten çünkü MELPA indirilmektedir paketlerine; ve (2) package.elpaketleri güncellemek için kullandığınızda , deponuzda değişmemiş değişiklikleriniz olur ve paket güncellemelerini dahil etmek için bir taahhütte bulunmanız gerekir.
Radon Rosborough

Çok teşekkürler. Bir şey daha var: MELPA'nın güncellemeleri otomatik olarak paketlediğini düşündüm. Durum böyle değil mi?
space_voyager

1
@space_voyager: Tabii ki uzak paket deposu güncellenecek, ancak paketlerin güncellenmiş sürümleri yerel makinenize otomatik olarak indirilmiyor ve kurulmuyor. Bunun için ihtiyacınız var M-x list-packages RET U.
Radon Rosborough

1
@Lassi Kısa cevap: Emacs'ı kurmak istediğiniz her şeyi kullanın; straight.elyalnızca Emacs paketlerini yüklemek için kullanın . Nix harika bir fikir, ama bildiğim kadarıyla Emacs paket gelişimi için iyi optimize edilmedi (lütfen yanılıyorsam beni düzeltin) . Emacs paketlerini yüklemek için bir sistem paketi yöneticisi kullanırsanız, yalnızca kaynak kodlarını düzenleyemez ve ardından değişikliklerinizi işleme koyamazsınız. En son Emacs paketleri için bir Nix konfigürasyonuna baktığımda, aşırı karmaşık ve genellikle straight.elgeliştirme deneyiminden daha düşük görünüyordu . Sana nasıl uyuyorsa.
Radon Rosborough

11

Use -package kullanıyorsanız , bu dosyayı bilgisayardan bilgisayara taşıyabilirsiniz ve Emacs başladığında, internet erişiminiz olduğu sürece paketleri çeker ve yapılandırır.

İlk olarak, paket kitaplığını ayarlayın:

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

Ve sonra bootstrap use-package:

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

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

Şimdi, Emacs'ı yapılandırmak ve paketlerin kurulu olduğunu varsaymak yerine, use-packagebunları hem yüklemek hem de yapılandırmak için kullanın. Örneğin, dümen ayarlarımdan bazıları için:

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

Dikkat edin, bu yapılandırmayı içeri alır init.el, ancak daha fazlası vardır. Örneğin, bu dabbrev dosyalarını veya özel snippet'lerinizi veya bir ton başka bir şeyi barındırmaz.
Omair Majid

Evet. Yapılandırmanızın bir parçası olan başka dosyalarınız varsa, onları da init dosyanızla birlikte taşımanız gerekir.
zck

o noktada, yine "hangi dosya aslında benim yapılandırmamın bir parçası ve nasıl benim makineleri arasında senkronize tutmak" bir oyun haline gelir :(
Omair Majid

Eklemek gerekir :ensure tiçin use-packagebeyanname veya setine use-package-always-ensurekadar t. Aksi takdirde, yapılandırma kopyalandığında başka bir sisteme otomatik olarak yüklenmez.
Chakravarthy Raghunandan

6

İle yeni nesil paket yönetimi straight.el

package.elPaketlerimi yönetmek için + Quelpa'yı kullanmak için uzun ve sinir bozucu bir mücadeleden sonra mermiyi ısırdım ve kendi paket yöneticimi yazdım . Neredeyse her açıdan package.elüstün bir paket yönetim deneyimi sağlayarak tamamen yerini alması amaçlanmıştır .

Tüm özellikleri hakkında bilgi edinmek için çok kapsamlı belgeleri okuyabilirsiniz , ancak bu soru ile en alakalı olanı mükemmel tekrarlanabilirliğestraight.el odaklanmasıdır . Bu, Emacs'ı normal olarak başlatmanızın veya yeni bir makinede başlatmanızın önemli olmaması ve yerel değişikliklerin sürüm kontrollü olması ve standart bir duruma döndürülebilmesi anlamına gelmez. Pratik olarak, bunu (1) Git depoları olarak paketleri klonlamak ve durumlarını yönetmek için otomatik araçlar sağlamak; (2) init dosyasını başka bir yerde depolanabilir hiçbir veri olmadan paket yönetimi durumu için tek gerçek kaynak olarak kullanmak ; ve (3) her paketin kesin Git revizyonlarını, ayrıca tüm reçete depolarını vestraight.el kendisi.

Başlamak için , yüklenecek ve etkinleştirilecek önyükleme snippet'ini takın straight.el. Ardından, bir paketin kurulu olduğundan emin olmak straight-use-packageiçin init dosyanıza bir çağrı yapmanız yeterlidir :

(straight-use-package 'projectile)

Evet, bu kadar basit. package-refresh-contentsO çöple uğraşmak yok . Bu formu init dosyanızdan kaldırır ve Emacs'ı yeniden başlatırsanız, Projectile artık yüklenmez (aksine package.el). Bu, yanlışlıkla bir şekilde bildirilmeyen paketlere bağımlı olduğunuz için yapılandırmanızın bir şekilde yeni bir makinede çalışmadığı konusunda endişelenmenize gerek olmadığı anlamına gelir.

İnit dosyanız boyunca paketleri istediğiniz zaman ve istediğiniz zaman kurabilirsiniz (bunların listesini tek bir noktada bildirmenize gerek yoktur). Tabii ki sadece

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

listeyi tercih ederseniz. Ancak use-packagepaket yapılandırmanızı yönetmek için kullanmanızı öneririz . İlk önce yüklemeniz gerekir:

(straight-use-package 'use-package)

Ardından, straight.elyerleşik entegrasyonundan bu yana , use-packageaşağıdaki "sadece çalışır":

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

İnit dosyanızı ihtiyaç duyduğunuz paketleri yüklemek için yazdıktan sonra, M-x straight-freeze-versionsbir sürüm kilit dosyasını kaydetmek için çalıştırın ~/.emacs.d/straight/versions/default.el. straight.elEmacs'ı yeni bir makinede ilk kez başlattığınızda, bu dosyayı sürüm kontrolünde tutmalısınız . (Manuel olarak kilit dosyasında belirtilen sürümlere geri dönebilirsiniz M-x straight-thaw-versions.)

Ben bahsedilen o makine yerel dotfiles fikrini desteklemek için benim diğer cevap , straight.elbir sunan profil sistemi . Hala nokta dosyalarınız için sembolik bağlantılar kullanmanızı öneririm (bu durumda, init.elvarsa yerel init dosyanız ve kullanmak istiyorsanız kilit dosyası).

straight.elDiğer paket yöneticileriyle nasıl karşılaştırıldığını merak ediyorsanız , kapsamlı karşılaştırmalar bölümüne göz atın . Ancak diğer her şey hakkında daha fazla dokümantasyon var .


4

Paketlerinizi yönetmek için fıçı kullanabilirsiniz . Kaynak kontrolünü yapmak ve emacs dot dosyalarınızı senkronize etmek için git / github komutunu kullanın.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.