Como obter o mesmo ambiente Emacs em um computador diferente?


16

Sou iniciante no Emacs (usei-o por cerca de duas semanas e adoro). À medida que atualizo e expiro meu ~/.emacs.d/init.elarquivo, as coisas que escrevo nele dependem de certos pacotes que instalei do MELPA usando M-x package-install, de .elarquivos que eu mesmo escrevi etc.

Minha pergunta é: devo, no futuro, trocar de computador, por exemplo, qual é a melhor maneira de obter perfeitamente o mesmo ambiente Emacs exato no novo computador que eu tenho agora?


3
Desde que você possa se movimentar init.el(usando o git, por exemplo), essa abordagem também funcionará (com base em use-package): lunaryorn.com/posts/…
— VanLaser

Uma abordagem é colocar o diretório .emacs.d no Dropbox. Eu só usei em computadores com o mesmo sistema operacional. Diferentes tipos de * nix devem estar ok, mas você pode ter problemas se tentar compartilhar entre máquinas executando sistemas operacionais muito diferentes.
— Qudit

Esta pergunta está muito próxima a emacs.stackexchange.com/q/408/2710 . Você pode destacar as diferenças?
— Andrew Swann

Para quem não é programador, como eu, sincronizar a configuração e os pacotes do emacs em três máquinas (duas janelas, um OSX) usando o Google Drive tem sido eficaz e confiável. Isso funciona porque o emacs e a maioria de seus pacotes são amplamente independentes de plataforma. A reprodução entre plataformas de uma experiência idêntica do emacs requer apenas algumas linhas no arquivo init.el para resolver caminhos específicos do SO para o diretório de pacotes sincronizados do emacs.
— Snelephant

Sua configuração é o ~/.emacs.ddiretório inteiro ; portanto, use o método que você preferir para sincronizar isso entre as máquinas. (por exemplo, um repositório do Github, uma pasta do Dropbox ou o que for melhor para você).
— phils

Respostas:


9

A solução correta é usar straight.el, um gerenciador de pacotes que escrevi para resolver esse problema. Você pode encontrar mais detalhes sobre isso em outra resposta a esta pergunta .

Essa resposta, que foi escrita meses antes de eu começar a trabalhar straight.el, descreveu anteriormente uma maneira estritamente inferior de obter uma solução parcial. Esta abordagem é descrita brevemente abaixo; Eu não recomendo mais.

Mesmo se você não quiser usar straight.el, você deve pelo menos adotar use-package. (Não que os dois sejam mutuamente exclusivos - acredito que a configuração mais limpa vem do uso de ambos.)


Comece definindo uma lista de pacotes no seu arquivo init:

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

Em seguida, instale-os automaticamente:

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

Se você mantiver seu init.elarquivo sob controle de versão, sincronizá-lo com outra máquina resultará na instalação automática dos pacotes. Obviamente, as versões instaladas serão completamente diferentes e, como resultado, não se pode esperar que sua configuração funcione imediatamente. Essa é uma falha fundamental package.ele é uma das razões pelas quais essa abordagem é ruim. Veja novamente straight.el. Observe também que o código descrito acima separa sua lista de pacotes da sua configuração para esses pacotes, dificultando o controle das coisas no seu arquivo init. Essa é outra grande desvantagem. Veja novamente use-package.


Obrigado pelo artigo! Se eu optar por hospedar tudo no Github, incluindo os pacotes que baixei do MELPA, isso manterá a capacidade do MELPA de atualizar automaticamente os pacotes no novo computador?
— space_voyager

1
@space_voyager Sim, tudo ainda vai acontecer da mesma maneira. No entanto: (1) quando você clona em um computador novo, o Emacs não precisa baixar pacotes do MELPA, porque eles já estão no repositório que você acabou de clonar; e (2) sempre que você usar package.elpara atualizar pacotes, você terá alterações sem etapas no seu repositório e precisará fazer uma confirmação para incluir as atualizações do pacote.
— Radon Rosborough 17/10/19

Ótimo, obrigado. Mais uma coisa: achei que o MELPA faz atualizações de pacotes automaticamente. Não é este o caso?
— space_voyager

1
@ space_voyager: Bem, é claro que o repositório de pacotes remotos será atualizado, mas as versões atualizadas dos pacotes não são baixadas e instaladas na sua máquina local automaticamente. Para isso você precisa M-x list-packages RET U.
— Radon Rosborough 17/10/16

1
@Lassi Resposta curta: use o que você deseja instalar o Emacs; use straight.elapenas para instalar pacotes Emacs. Nix é uma ótima idéia, mas não é muito otimizado para o desenvolvimento de pacotes Emacs, tanto quanto eu sei (por favor, corrija-me se estiver errado) . Se você usar um gerenciador de pacotes do sistema para instalar os pacotes do Emacs, não poderá editar apenas o código-fonte e, em seguida, confirmar e enviar suas alterações pelo upstream. Da última vez que olhei para uma configuração Nix para pacotes Emacs, ela parecia excessivamente complexa e geralmente inferior à straight.elexperiência de desenvolvimento. Mas, o que quer que flutue no seu barco.
— Radon Rosborough

11

Se você usar o pacote de uso , poderá mover esse arquivo de um computador para outro e, quando o Emacs iniciar, desde que você tenha acesso à Internet, ele puxará os pacotes e os configurará.

Primeiro, configure a biblioteca de pacotes:

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

E então bootstrap use-package:

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

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

Agora, em vez de configurar o Emacs e assumir que os pacotes estão instalados, use-os use-packagepara instalar e configurá-los. Por exemplo, para algumas das minhas configurações de leme:

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

Veja bem, isso fornece a configuração (in init.el), mas há muito mais. Por exemplo, isso não irá portar os arquivos do dabbrev, seus trechos personalizados ou muitas outras coisas.
— Omair Majid

Sim. Se você tiver outros arquivos que fazem parte da sua configuração, precisará movê-los também, juntamente com o seu arquivo init.
— chave ZCK

nesse ponto, ele novamente se torna um jogo de "qual arquivo é realmente parte da minha configuração e como eu o mantenho sincronizado em minhas máquinas" :( #
— Omair Majid Majid

você deve adicionar :ensure tà use-packagedeclaração ou definir use-package-always-ensurecomo t. Caso contrário, ele não seria instalado automaticamente em outro sistema quando a configuração fosse copiada.
— Chakravarthy Raghunandan

6

Gerenciamento de pacotes de última geração com straight.el

Após uma longa e frustrante luta para usar o package.el+ Quelpa para gerenciar meus pacotes, eu mordi a bala e escrevi meu próprio gerenciador de pacotes . Ele pretende substituir completamente package.el, fornecendo uma experiência de gerenciamento de pacotes superior em quase todos os aspectos.

Você pode ler a documentação muito extensa para aprender sobre todos os seus recursos, mas o mais relevante para essa questão é o straight.elfoco na reprodutibilidade perfeita . Isso significa que não importa se você está iniciando o Emacs normalmente ou em uma nova máquina, e que quaisquer alterações locais são controladas por versão e podem ser revertidas para um estado canônico. Na prática, isso é conseguido (1) pela clonagem de pacotes como repositórios Git e pelo fornecimento de ferramentas automatizadas para gerenciar seu estado; (2) usando o arquivo init como a única fonte de verdade para o estado de gerenciamento de pacotes, sem dados mutáveis ​​armazenados em outro local; e (3) usando arquivos de bloqueio de versão opcionais para especificar revisões exatas do Git de cada pacote, além de repositórios de receitas estraight.el em si.

Para começar, insira o snippet de inicialização , que será instalado e ativado straight.el. Então, para garantir que um pacote esteja instalado, basta fazer uma chamada straight-use-packageno seu arquivo init:

(straight-use-package 'projectile)

Sim, é simples assim. Nada de lidar com package-refresh-contentsesse lixo. Se você remover este formulário do seu arquivo init e reiniciar o Emacs, o Projectile não será mais carregado (ao contrário de package.el). Isso significa que você não precisa se preocupar com a configuração de alguma forma não funcionar em uma nova máquina, porque você acidentalmente dependeu de pacotes não declarados.

Você pode instalar pacotes onde e quando quiser, em todo o seu arquivo init (não é necessário declarar uma lista deles em um único ponto). Claro que você também pode fazer

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

se você preferir a lista. No entanto, recomendo que você use use-packagepara gerenciar sua configuração de pacote. Primeiro você precisa instalá-lo:

(straight-use-package 'use-package)

Então, como ele straight.elpossui integração interna use-package, o seguinte "simplesmente funciona":

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

Depois de escrever seu arquivo init para instalar os pacotes necessários, execute M-x straight-freeze-versionspara salvar um arquivo de bloqueio da versão ~/.emacs.d/straight/versions/default.el. Você deve manter esse arquivo sob controle de versão, pois ele permitirá straight.elverificar as versões corretas de todos os seus pacotes quando você iniciar o Emacs em uma nova máquina. (Você pode reverter manualmente para as versões especificadas no arquivo de bloqueio usando M-x straight-thaw-versions.)

Para apoiar a idéia de arquivos de pontos locais da máquina que mencionei na minha outra resposta , straight.eloferece um sistema de perfil . Eu ainda recomendo usar links simbólicos para seus arquivos de ponto (nesse caso, init.elseu arquivo init local, se aplicável, e a versão lockfile, se você quiser usar um).

Se você está se perguntando como se straight.elcompara com outros gerenciadores de pacotes, consulte a seção de comparações extensivas . Mas há muito mais documentação sobre todo o resto também.


4

Você pode usar o cask para gerenciar seus pacotes. Use o git / github para controlar a fonte e sincronizar seus arquivos de pontos do emacs.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.