¿Ventajas de establecer variables con setq en lugar de custom.el?

Veo que muchas personas (autores de extensiones y otros) dan ejemplos de configuración con setq:

(setq foo 'bar)

Estos parámetros a menudo se definen con defcustom, haciéndolos disponibles para su personalización custom.el.

Normalmente uso custom.elpara configurarlos. ¿Tendría alguna ventaja usarlo setqo los dos métodos son más o menos equivalentes?

Algunas personas pueden pensar que es más fácil de usar setq. Algunas personas pueden pensar que es más lispy. En realidad, es ingenuo en el caso general.

Es cierto que para algunas opciones de usuario no importa. Pero para otros, sí importa, y setqes el enfoque equivocado para esas opciones. Entonces, como regla general, setqes el enfoque equivocado.

Si usa custom-set-variableso en customize-set-variablelugar de setq, o si usa la interfaz de usuario Personalizar (por ejemplo M-x customize-option), entonces está seguro de que cualquier código de inicialización o actualización que se necesite para el valor de la opción se activará automáticamente y se ejecutará según sea necesario. Si lo usa setq, esto no se hará.

Ahora, también es el caso de que la mayoría de las opciones de usuario, especialmente muchas de ellas escritas para bibliotecas de terceros, no hacen uso de las defcustompalabras clave :sety :initialize, y el uso setqno es importante para ellas. Pero muchas opciones de Emacs vanilla utilizan esas palabras clave, y para aquellos que lo hacen, setqno es lo correcto. Entonces, si desea usar el código Lisp y no la interfaz de usuario Personalizar para configurar sus opciones, es mejor que use custom-set-variableso en customize-set-variablelugar de setq. Nunca duele y a veces ayuda (mucho).

Pero lo que recomiendo es hacer ambas cosas:

• Use la interfaz de usuario Personalizar en lugar de escribir el código Lisp para esto.

• Defina variablecustom-file , de modo que Personalizar escriba personalizaciones en ese archivo y no en su archivo de inicio ( ~/.emacs). IOW, mantenga su código de inicialización escrito a mano separado del código automático escrito por Customize.

Prefiero setqterminar customizepor varias razones:

1. En primer lugar, permite que las variables se establezcan mediante programación (como en, (setq foo (calculate-foo))). Utilizo este poder todo el tiempo en mi configuración para mantener las cosas SECAS. Para mí, el objetivo de usar Emacs es la capacidad de programación, y la customizeinterfaz no hace más que interponerse.
2. setqse presta mejor para el control de versiones y la organización del código. Dividí mi inicialización entre docenas de archivos; Si todo estuviera en un custom.elarchivo enorme , sería mucho más difícil encontrar y editar configuraciones rápidamente.
3. Esto es subjetivo, pero para mí toda la customizeinterfaz se siente como una reliquia horrible de las peores interfaces de usuario de los 90. Prefiero editar texto con el poder de Emacs cualquier día.

@Drew hace algunos buenos puntos sobre algunas sutilezas con :sety :initialize. He estado usando Emacs durante años y rara vez he encontrado problemas como ese. Cuando lo haga, es fácil que cambiar setqpara custom-set-variableen casos específicos.

Una ventaja de usar en setqlugar de customizees la legibilidad. Uno es libre de anotar cada personalización a su gusto, lo que IMO mejora la legibilidad. También se pueden agrupar personalizaciones relacionadas, lo que mejora la modularidad. Finalmente, diría que navegar por un búfer de elisp es más "fácil" que navegar por la interfaz de usuario y los widgets personalizados.

Por otro lado, personalizar le permite volver fácilmente a los valores predeterminados que pueden ser invaluables cuando las cosas se vuelven locas.

EDITAR: la respuesta de Drew proporciona una gran razón para usar customize-set-variablesque puede proporcionar todas las ventajas que señalé. Sin embargo, la IU personalizada no se presta a configuraciones portátiles entre diferentes plataformas tan fácilmente como lo hace el elisp sin formato. Si necesita que una variable tenga una configuración dependiente del sistema operativo, tendrá que recurrir a elisp en muchos casos. Mi punto sobre una navegación más fácil en los buffers de elisp sigue en pie.

Otra alternativa es usar el paquete de uso de John Wiegley . Esto proporciona una forma programática de configurar paquetes que funciona bien con el proceso de inicialización de paquetes de emacs 24+. Aquí hay un ejemplo de uso del archivo Léame:

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

El punto es que use package es una macro y no evalúa sus argumentos de inmediato. Los parámetros :inity :configse evalúan en diferentes etapas del proceso de inicialización, lo que permite tener la configuración de cada paquete en un solo lugar, pero hacer que cada parte se ejecute en la etapa apropiada de inicialización.

Sin algo como use-packagealgunos paquetes requieren que parte de su código de inicialización vaya antes (package-initialize)y otra parte que vaya después. Si tienes muchos packegas así, entonces tus inicializaciones tendrían que ser intercaladas.

Otro beneficio use-packagees que puede instalar automáticamente los paquetes que faltan al usar package.el si lleva sus .emacs a una nueva máquina o si comparte su configuración con otro usuario y toda la inicialización puede diferirse hasta que un paquete realmente necesite cargarse.

También hay argumentos de palabras clave adicionales que permiten un mayor control sobre el proceso de inicialización.

Dicho todo esto, una gran ventaja de personalizar es que muestra lo que hay que configurar en un paquete dado. Esa es una razón por la que todavía lo uso para muchos de mis paquetes.