Vantagens de definir variáveis ​​com setq em vez de custom.el?

Vejo muitas pessoas (autores de extensão e outros) dar exemplos de configuração com setq:

(setq foo 'bar)

Esses parâmetros geralmente são definidos com defcustom, disponibilizando-os para personalização custom.el.

Eu normalmente uso custom.elpara configurá-los. Em vez disso, haveria alguma vantagem em usar setqou os dois métodos são aproximadamente equivalentes?

Algumas pessoas podem pensar que é mais simples de usar setq. Algumas pessoas podem pensar que é mais lispy. Na realidade, é ingênuo no caso geral.

É verdade que, para algumas opções de usuário, isso não importa. Mas para outros, isso importa, e setqé a abordagem errada para essas opções. Então, como regra geral, setqé a abordagem errada.

Se você usar custom-set-variablesou em customize-set-variablevez de setq, ou se você usar a interface do usuário Personalizar (por exemplo M-x customize-option), terá certeza de que qualquer código de inicialização ou atualização pretendido necessário para o valor da opção será automaticamente acionado e executado conforme necessário. Se você usar setq, isso não será feito.

Agora, também é o caso de a maioria das opções de usuário, especialmente muitas escritas para bibliotecas de terceiros, não fazem uso das defcustompalavras - chave :sete :initialize, e o uso setqnão importa para elas. Mas muitas opções de baunilha do Emacs usam essas palavras-chave e, para aquelas que o fazem, setqnão é a coisa certa. Portanto, se você deseja usar o código Lisp e não a interface do usuário Personalizar para definir suas opções, é melhor usar custom-set-variablesou em customize-set-variablevez de setq. Nunca dói e às vezes ajuda (muito).

Mas o que eu recomendo é fazer as duas coisas:

• Use a interface do usuário Personalizar em vez de escrever o código Lisp para isso.

• Defina a variávelcustom-file , para que o Customize grave personalizações nesse arquivo e não no seu arquivo init ( ~/.emacs). IOW, mantenha seu código de inicialização escrito à mão separado do código automático escrito por Customize.

Prefiro setqmais customizepor vários motivos:

1. Em primeiro lugar, ele permite que as variáveis ​​sejam configuradas programaticamente (como em (setq foo (calculate-foo))). Eu uso esse poder o tempo todo em minha configuração para manter as coisas secas. Para mim, o objetivo principal do uso do Emacs é a programação, e a customizeinterface não faz nada além de atrapalhar.
2. setqpresta-se melhor ao controle de versão e organização de código. Dividi minha inicialização entre dezenas de arquivos; se tudo estivesse em um custom.elarquivo enorme , seria muito mais difícil encontrar e editar rapidamente as configurações.
3. Isso é subjetivo, mas para mim toda a customizeinterface parece uma relíquia horrível das piores UIs dos anos 90. Eu preferiria editar texto com o poder do Emacs qualquer dia.

@Drew faz alguns pontos positivos sobre algumas sutilezas com :sete :initialize. Uso o Emacs há anos e raramente encontro problemas assim. Quando eu faço, é fácil de trocar setqpara custom-set-variableem casos específicos.

Uma vantagem de usar em setqvez de customizeé legibilidade. Um é livre para anotar cada personalização ao seu gosto, o que IMO melhora a legibilidade. Também é possível agrupar personalizações relacionadas, o que melhora a modularidade. Finalmente, eu diria que navegar através de um buffer elisp é mais "fácil" do que navegar na interface do usuário e nos widgets.

Por outro lado, a personalização permite reverter facilmente para valores padrão que podem ser inestimáveis ​​quando as coisas dão errado.

EDIT: A resposta de Drew fornece uma excelente razão para usar, customize-set-variablesque pode fornecer todas as vantagens que apontei. No entanto, a UI de personalização não se presta a configurações portáteis entre plataformas diferentes tão facilmente quanto o elisp bruto. Se você precisar que uma variável tenha a configuração dependente do sistema operacional, será necessário fazer o fallback para elisp em muitos casos. Meu argumento sobre a navegação mais fácil nos buffers elisp ainda permanece.

Outra alternativa é usar o pacote de uso de John Wiegley . Isso fornece uma maneira programática de configurar pacotes que funcionam bem com o processo de inicialização de pacotes do emacs 24+. Aqui está um exemplo de uso do leia-me:

(use-package color-moccur
  :commands (isearch-moccur isearch-all)
  :bind (("M-s O" . moccur)
         :map isearch-mode-map
         ("M-o" . isearch-moccur)
         ("M-O" . isearch-moccur-all))
  :custom (isearch-lazy-highlight t)
  :config (use-package moccur-edit))

O ponto é que use package é uma macro e não avalia seus argumentos imediatamente. Os parâmetros :inite :configsão avaliados em diferentes estágios do processo de inicialização, possibilitando a configuração de cada pacote em um único local, mas cada parte sendo executada no estágio apropriado de inicialização.

Sem algo parecido, use-packagealguns pacotes exigem que parte de seu código de inicialização seja anterior (package-initialize)e outra parte seja posterior. Se você tem muitos pacotes assim, suas primeiras inicializações teriam que ser intercaladas.

Outro benefício use-packageé que ele pode instalar automaticamente os pacotes ausentes usando o package.el se você levar o .emacs para uma nova máquina ou se você compartilhar sua configuração com outro usuário e toda a inicialização puder ser adiada até que um pacote realmente precise ser carregado.

Também existem argumentos de palavras-chave adicionais que permitem mais controle sobre o processo de inicialização.

Tudo o que foi dito, uma grande vantagem da personalização é que ela mostra o que há para ser configurado em qualquer pacote. Essa é uma das razões pelas quais ainda o uso em muitos dos meus pacotes.