Tengo el código elisp que me gustaría ejecutar en los archivos de orgmode cuando se cargan (diferentes para diferentes archivos y definidos en el archivo). ¿Hay alguna forma de hacer esto? No vi nada en http://orgmode.org/manual/In_002dbuffer-settings.html
Si puedo agregar algo a la inicialización de emacs que ejecuta un bloque de código con un nombre especial cada vez que se carga un archivo orgmode, podría ser una solución, pero no estoy seguro de cómo hacerlo, e idealmente hay algo incorporado.
# -*- eval: (lisp code here) -*-
pero también debe ser consciente de los peligros. Incluso si no comparte estos documentos con nadie más, la naturaleza interpretada de Emacs Lisp significará que un cambio puede ocasionar accidentalmente la pérdida de datos. Además, el modo de enlace suena como una mejor opción si desea ejecutar el mismo código para más de un archivo.Respuestas:
Esta solución no requiere cambios en
init.el
(con modificaciones menores). Sin embargo, implica evaluaciones locales de archivo, pero eso es exactamente lo que solicitó el OP. Las ventajas de la solución son:init.el
el archivo orgmode, puede compartirse entre usuarios (de confianza)Estoy reformulando la solución aquí.
Agregue un bloque src en algún lugar de su archivo:
Luego, coloque esto al final de su orgmode-file:
Agregué
(outline-hide-sublevels 1)
porque me gusta ocultar el bloque src dentro de un encabezado y quiero que los subniveles se oculten en el inicio. Sin esta declaración, los subniveles se expandirán por(org-babel-goto-named-src-block "startup")
.Con esta solución, emacs pedirá 2 veces permiso para ejecutar (primero: aplicar variables locales; segundo: ejecutar "inicio" -src-block). Como tengo muchos bloques src en mi archivo, configuré otra variable local de archivo
org-confirm-babel-evaluate
, como esta:Advertencia: con esta adición, emacs solicitará solo una vez permiso para ejecutar; todos los bloques src en ese archivo ahora se pueden ejecutar sin más confirmación. Como otros han señalado antes, este comportamiento podría ser peligroso y debe tener mucho cuidado con esta configuración.
Sin embargo, argumentaría que esta solución (especialmente la primera versión) es más segura que la que ofrece Joe Corneli porque al menos se le pedirá confirmación para ejecutar. La solución de Joe evaluará el bloque especial sin confirmación, si se encuentra en el archivo. Un atacante tendría que adivinar el nombre del bloque especial, por supuesto ...
Estoy usando este enfoque para escribir documentos grandes que requieren, por ejemplo, adaptaciones a los mecanismos de exportación de la organización.
fuente
Entonces, en su init.el:
fuente
Ya que pides
entonces, prueba esta solución .
fuente
Estoy de acuerdo con la sugerencia de @Joe Corneli sobre el uso de un gancho.
También se me ocurre que podría aprovechar los marcadores aquí: coloque un salto de marcador específico en el gancho. Una ventaja de un marcador para el bloque de código es que generalmente se reubica automáticamente (por ejemplo, a medida que cambia el contenido del archivo), por lo que la ubicación del bloque generalmente se debe solucionar automáticamente.
[Pero no me queda claro por qué tiene el código en los archivos del modo Org, en lugar de en otro lugar. Estamos tomando eso como algo dado, según el enunciado del problema, pero me pregunto por qué lo está haciendo. Hacernos saber más sobre el diseño a ese respecto podría conducir a una mejor ayuda.]
fuente
He intentado mejorar el código de Joe Corneli:
Lo necesita en su archivo init.el:
Cada vez que abra un búfer de modo org, buscará un bloque de origen llamado startblock, si lo encuentra, lo ejecutará.
En sus archivos de modo org, puede poner:
fuente