Ring Run dev workflow de LLL

Motivación

Evitar XCode en cuanto sea posible. Solo se usa xcodebuild si se tocaron fuentes C/Obj-C.
Comandos y funciones de conveniencia para iniciar y controlar RR desde Emacs.
Forma fácil de evaluar chunks y expresiones en el contexto del RR desde Emacs.
Chequeo básico de sintaxis antes de largar el juego y mientras se edita un archivo.

tl;dr:

Las configuraciones están acá.

Compilando Ring Run

Usar M-x compile para llamar a xcodebuild y compilar el proyecto para todas las plataformas. La forma fácil de configurar compile es incluir un .dir-locals.el en la raiz del proyecto con:

;; sustituir ~/dev/ringrun por la ruta a la raiz del proyecto
((nil . (
         (compile-command . "cd ~/dev/ringrun/src/RingRun && xcodebuild -configuration Debug")
         )))

Los errores en la compilación o en la generación de bytecode de lua se pueden ir recorriendo con C-x ` si uno no está usando flymake; o cambiando al buffer *compilation* y avanzando con M-n, M-p.

Corriendo Ring Run

Estando en cualquier archivo lua bajo src/common, usar M-x rr-launch-ringrun para correr Ring Run. El output del proceso va al buffer *Async Shell Command*. Si se quiere terminar el proceso en ejecución y arrancarlo nuevamente, basta con llamar a rr-launch-ringrun de nuevo.

Además ringrun.el define otros comandos de conveniencia como

    rr-restart-level  ;; reinicia el nivel actual, por defecto C-c r desde un buffer lua.
    rr-toggle-pause   ;; por defecto C-c t desde un buffer lua.
    rr-value-at-point ;; imprimir el valor del símbolo bajo el cursor en el REPL

Estos comandos usan el REPL para invocar funciones lua definidas en localuser.lua que realizan el trabajo de verdad.

REPL y evaluación de chunks

Usar el REPL desde Emacs requiere mi fork de lua-mode. Hay dos variables de lua-mode que definen cual es el comando que invoca a un interprete lua, que en este caso tiene la cara de una sesión de telnet que se conecta al REPL remotamente:

    (setq-default lua-default-application "telnet")
    (setq-default lua-default-command-switches (list  "localhost" "9000"))

Los comandos más útiles de lua-mode están configurados en keybindings amistosos:

(eval-after-load 'lua-mode
  '(progn 
     (define-key lua-mode-map (kbd "C-c C-r") 'lua-send-region)
     (define-key lua-mode-map (kbd "C-c C-c") 'lua-send-buffer)
     (define-key lua-mode-map (kbd "C-c C-l") 'lua-send-current-line)
     (define-key lua-mode-map (kbd "C-M-x") 'lua-send-proc)
     (setq lua-always-show nil) ;; define si el buffer del interprete se debe mostrar luego de cada lua-send-*
     (add-hook 'lua-mode-hook 'flymake-lua-setup)))

Al intentar ejecutar cualquiera de los comandos anteriores, Emacs inicia el proceso telnet, se conecta al REPL y envía el chunk correspondiente. De ahí en adelante el REPL está accesible en el buffer *telnet*.

En general, además de localuser.lua, tengo un buffer debug.lua en el cual voy agregando lineas con cosas que quiero imprimir, o funciones globales auxiliares, que voy invocando con C-c C-l según sea necesario.

Flymake para chequeo de sintaxis

Uso flymake para detectar errores de sintaxis mientras estoy programando. La configuración de flymake que uso es:

(autoload #'flymake-lua-setup "flymake-lua" nil t)
(eval-after-load 'lua-mode
    '(progn 
    (add-hook 'lua-mode-hook 'flymake-lua-setup)))

Requiere tener flymake-lua.el en el load-path de emacs. En mi caso, flymake-lua-.el usa el directorio ~/tmp para hacer la byte-compilation de cada file. Pueden cambiarlo a /tmp o cualquier otro directorio ya existente.En mi caso ~/tmp es un mountpoint de un RAM drive para no estar escribiendo mugre a la flash todo el tiempo.

Fuentes y links

Todas mis configuraciones en este gist

legumbre/workflow.md