Emacs 24 Problemas de inicialización del sistema de paquete
dot-emacs emacs24 (2)
Me parece que el nuevo sistema de paquete que está incorporado en Emacs 24 tiene algunos defectos a la hora de cargar e inicializar correctamente los paquetes instalados.
Recientemente, actualicé a Emacs 24.1.1 que se publicó el 10/06/2012 y he intentado utilizar el sistema de paquete integrado y he instalado varios paquetes que lo usan, pero todos tienen un problema similar relacionado con la carga automática y inicialización
Por ejemplo, uso un paquete llamado smex
que proporciona mejoras para usar el acorde de Mx
. Requiere que defina una clave para Mx
, por lo que agregué (global-set-key (kbd "Mx") ''smex)
en mi archivo init.el
Pero después de iniciar emacs, presiono el acorde Mx
y aparece el mensaje "La definición de la función del símbolo es nula: smex" ... Si también puse (require ''smex)
en mi archivo init.el, aparece el mensaje de error "Error de archivo: No se puede abrir el archivo de carga, smex "
Sin embargo, la adición de la ubicación de smex a la variable de ruta de carga hace que funcione como se esperaba, lo que parece frustrar por completo el propósito de tener un sistema de paquete en primer lugar ...
¿Alguna idea? ¿Hay una manera mejor o vivimos con esta limitación por ahora?
Los paquetes que instala con package.el
se activan de manera predeterminada después de .emacs
su .emacs
. Para poder usarlos antes del final de tus .emacs
, necesitas activarlos usando los comandos:
(setq package-enable-at-startup nil)
(package-initialize)
Vale la pena señalar por qué Emacs aplaza la inicialización del paquete:
Ver Ch i g (emacs) Package Installation
RET , y en particular:
La razón por la que se carga el paquete automáticamente después de cargar el archivo de inicio es que las opciones de usuario solo reciben sus valores personalizados después de cargar el archivo de inicio, incluidas las opciones de usuario que afectan el sistema de embalaje. En algunas circunstancias, es posible que desee cargar paquetes explícitamente en su archivo init (generalmente porque algún otro código en su archivo init depende de un paquete). En ese caso, su archivo init debería llamar a la función
package-initialize
. Depende de usted asegurarse de que las opciones de usuario relevantes, como lapackage-load-list
(ver a continuación), estén configuradas antes de la llamada depackage-initialize
delpackage-initialize
. También debe establecerpackage-enable-at-startup
ennil
, para evitar cargar los paquetes nuevamente después de procesar el archivo init. Alternativamente, puede elegir inhibir completamente la carga del paquete al inicio e invocar el comandoMx package-initialize
para cargar sus paquetes manualmente.
Por lo tanto, si se asegura de que su archivo init se encarga de los valores no predeterminados que desee para las variables en el grupo de personalización del package
1 antes de llamar al package-initialize
, y de que mantiene este enfoque siempre que personalice la configuración de la biblioteca del paquete, debería estar bien para hacer esto.
Alternativamente, como after-init-hook
ejecuta después de que se haya completado la inicialización del paquete estándar, puede usarlo para evaluar cualquier código de inicio que dependa de los paquetes. Entonces, en lugar de llamar package-initialize
directamente en init.el, en su lugar podrías escribir:
(add-hook ''after-init-hook ''my-after-init-hook)
(defun my-after-init-hook ()
;; do things after package initialization
)
poniendo el código que requiere el sistema de paquete inicializado dentro de esa función.
YMMV.
(nb) No he probado el enfoque after-init, ya que realmente no uso package.el, pero confirmé la secuencia de eventos en el código de inicio, así que creo que funcionará como se describe.
package
RET de 1 Mx customize-group
RET