¿Es posible instrumentar un archivo de configuración alfabetizado en modo Org con un archivo Emacs Lisp de respaldo?

Es una práctica común escribir archivos de configuración de Emacs usando un estilo de programación alfabetizado en modo Org.

Desafortunadamente, al tiempo que mejora la legibilidad, esto conlleva importantes desventajas de programación. En particular, dado que no hay un .elarchivo de respaldo , Emacs solo conoce el código en el bloque fuente actual. Esto significa que, excepto por el bloque editado actualmente, la navegación, la definición del símbolo y el chequeo no están disponibles.

#+BEGIN_SRC emacs-lisp
  (defun literate-but-invisible ()
    (interactive)
    (message "I close my eyes..."))
#+END_SRC

#+BEGIN_SRC emacs-lisp
  (defun humans-can-read-but-emacs-cannot ()
    (interactive)
    (literate-but-invisible) ; No navigation! Flycheck reports undefined symbol!
    (message "...so that the room will be empty"))
#+END_SRC

¿Hay alguna forma de decirle a Emacs que se enrede y use el .elarchivo generado para proporcionar estas características en modo Org? Tal característica mejoraría la capacidad de mantenimiento del código alfabetizado Emacs Lisp.

Tenga en cuenta que si bien sería una característica fantástica ver Flycheck trabajando para Org y Emacs Lisp simultáneamente en un búfer, solo estoy preguntando cómo instrumentar los org-editbúferes (el entorno que se obtiene cuando se invoca org-edit-special(generalmente C-c ')). Esto debería ser más fácil ya que solo hay un modo activo para el búfer.

He abierto una solicitud de función en el repositorio Flycheck aquí , y hay algunas investigaciones relevantes en otro tema aquí . Sin embargo, todavía no puedo construir una solución.

Para la navegación y la definición de símbolos, consulte https://github.com/jkitchin/scimax/blob/master/scimax-literate-programming.el

Puede generar un archivo TAGS con Mx scimax-lp-generate-tags.

Después de esto, puedo navegar a las definiciones de funciones con M-. y M-,. Necesita actualizar el archivo TAGS con esa función a medida que las cosas se mueven y se agregan, pero tal vez eso se pueda hacer en un gancho de almacenamiento intermedio de almacenamiento o algo así. También tenga en cuenta que esto proporciona etiquetas relativas al archivo org, no a dónde están las definiciones en los archivos fuente.

Mx scimax-lp-signature-doc obtendrá alguna información sobre el símbolo en el punto si está definido en el archivo org.

Desarrollé una forma conceptual para hacer que flycheck funcione en src-blocks en org-files. La idea es tener un archivo proxy que tenga el código enredado, exactamente en las mismas posiciones de caracteres (es decir, cambia todos los demás caracteres a espacios). Luego, deje que flycheck funcione en ese archivo. Luego, transfiera las superposiciones de flycheck del archivo proxy al archivo original. Configura una función de enlace para actualizar el archivo proxy al guardar y luego actualiza las superposiciones. Sorprendentemente, esto funciona bastante bien.

Puede ver el código en https://github.com/jkitchin/scimax/blob/master/scimax-ob-flycheck.org .

Así es como se ve un mal código

Después de activar scimax-ob-flycheck-mode, parece que:

 (defun org-literate-programming-eval-src-blocks ()
   "Auto evaluate Org buffer all source blocks to get a complete
 project environment when Literate Programming."
   (if (string= (buffer-name) "init.org")
       (org-babel-execute-buffer)))

 (add-hook 'find-file-hook #'org-literate-programming-eval-src-blocks :before)

El código superior agrega una función para evaluar todos los bloques de origen en el búfer que coincide con su archivo "init.org". El nombre del archivo se puede modificar según lo necesite.