Configurando Emacs para trabajar en un proyecto para android
Llevo tiempo desaparecido y es el momento de dar algunas explicaciones
sobre el porqué y de paso contar algo más sobre lo que estoy haciendo
y, de paso, sobre mis esfuerzos por ajustar el entorno de desarrollo
para trabajar más a mi gusto. Empezando, pues, por poner algo de
cordura en mi actividad, ahora prácticamente diaria, como programador
para Android®. Y sí, no nos vamos a engañar, el Android
Studio®1 trae integrado todo lo que necesita un programador para
crear aplicaciones para este S.O. y Emacs se queda corto en
funcionalidades. Sin embargo, la gran cantidad de recursos necesarios
para ejecutar «la mostra», te obligan a estar muy actualizado en
hardware. Hoy contaré cómo podemos ahorrarnos un poco de máquina con
la línea de comandos y nuestro editor favorito. He hecho pruebas con
Emacs sin, y con, eglot, encontrando algunas diferencias en el
método de trabajo de ambos modos.
Tareas fundamentales
Podemos desglosar las tareas fundamentales en las básicas para cualquier proyecto de software:
- Escribir código
- Compilar
- Probar el resultado
¿Podemos hacerlo todo sin recurrir a «la mostra»? eeeeeh, nos vamos
apañando, sí. Desde luego es mucho más cómodo entrar por el aro, mirar
a otro lado y arrancar la devoradora de recursos infinitos. Pero,
tenemos que recordar que copará, en poco rato un montón de Gigas de
memoria, la swap y lo que se tercie. De momento mi máquina aguanta
el asalto, mueve la mostra con soltura, pero soy consciente de que
en una o dos versiones más, no podrá con todo eso. Tirar del Studio
pronto será inviable y me voy curando en salud tirando más
directamente del Sdk desde línea de comandos.
En la lista anterior he obviado el asunto de mantener un repositorio
de código o depurar y perfilar la aplicación para hacerla más
eficiente y carente de errores. Sin olvidar tampoco todo lo referido a
documentación. Es decir, me voy a centrar en las tareas de
programación pura y dura. Para alguna de estas tareas, Emacs tiene
herramientas muy superiores a las que proporciona «la mostra», como
Magit para trabajar el repositorio de código u org-mode para
trabajar la documentación.
Muchas otras herramientas vienen a ayudar también, como projectile
para la gestión de proyectos, o ivy + company para el completado,
o flymake para la comprobación de errores, o xref para saltar a la
definición de variables y funciones, o yasnippet para la creación
asistida de módulos, clases y métodos. Por último, las pruebas con
eglot y eglot-java, para tener a mano las características tan de
moda de LSP.
Escribir código
Para escribir código sólo se necesita un buen editor con unas pocas características. La fundamental: el coloreado de sintaxis, para que las características del texto nos salten a la vista. Otras cosas como autocompletado, búsqueda de expresiones en el proyecto de trabajo, búsqueda rápida de expresiones en el documento, varios cursores para modificar el nombre de los elementos sólo una vez y sin errores. En fin, toda una serie de herramientas que nos proporciona Emacs que nos facilitan mucho la vida.
Compilar
Sin eglot podemos tirar de línea de comandos gracias a la
funcionalidad que nos proporciona Gradle para estos entornos.
> ./gradlew assembleOfficial
O si quieres depurar el código:
> ./gradlew assembleDebug
Luego veremos que con eglot podemos lanzar estos comandos desde
dentro de Emacs.
Probar el resultado
La forma de probar la aplicación es poder instalarla en algún
dispositivo externo para hacerlo. El emulador que viene con el Sdk
de Android®, también necesita recursos para su ejecución.
Lanzar el emulador:
> cd ~/Android/Sdk/emulator
> ./emulator -list-avids
INFO | Storing crashdata in: /tmp/android-notxor/emu-crash-34.2.15.db, detection is enabled for process: 35006
Mi_cacharro_virtual_API_33
Pixel_8_API_34
> ./emulator -change-language es -avd Mi_cacharro_virtual_API_33
En el emulador podemos ver qué dispositivos tenemos preparados. En mi
caso, tengo emulados dos dispositivos, con Android® 13 uno (la API 33)
y con Android® 14 el otro (la API 34). Después, le puedes decir
qué dispositivo quieres cargar. Es recomendable que miréis en la
documentación qué parámetros se pueden ajustar, como el que utilizo de
-change-language es para cambiar el idioma del aparato.
Una vez arrancado el emulador, podemos cargar la aplicación en el aparato emulado con otras sencillas instrucciones:
> cd ~/Android/Sdk/platform-tools > ./adb devices List of devices attached emulator-5554 device > ./adb install ~/Path/a/tu/aplicacion/mi-aplicacion-beta-debug.apk Performing Streamed Install Success >
El resultado:
Un inconveniente, en lo que respecta al uso de recursos, es que, muchas veces, Java se queda cargado en memoria. Si no lo vas a utilizar más veces y necesitas memoria, puedes liberar las 2GiB y pico, casi tres, que puede llegar a ocupar con estas herramientas.
Durante la ejecución también podemos consultar los logs que genera el dispositivo para seguir un poco más detalladamente qué está haciendo. Normalmente, en el código añadimos una instrucción del estilo:
Log.v(TAG, "@@@ Aquí el mensaje que quieras");
Después, cuando estamos ejecutando la aplicación desde la línea de comandos podemos hacer un seguimiento del logcat de la siguiente forma:
> adb logcat -e "@@@"
Filtrando por ese tipo de etiquetas nos evitamos un montón de mensajes que el dispositivo envía al log y que no están relacionadas con nuestra actividad directamente.
El proyecto aún está en fases muy preliminares y aún no ha sido necesario el uso del depurador para cazar algún bug.
Instalación de eglot y eglot-java
Para trabajar con Java podemos utilizar Emacs como un simple editor, es decir, coloreado de sintaxis y poco más. Sin embargo, muchos usuarios prefieren utilizar las funcionalidades que proporciona LSP.
eglot es un paquete interno que viene con Emacs, no necesitas
instalar nada para utilizarlo, pero siempre es bueno tenerlo
actualizado. Por ello, lo añadí a mi init.el junto con eglot-java
para trabajar.
(use-package eglot :defer t)
Como digo, eglot es uno de los paquetes built-in de Emacs. Sin
embargo, el avisar de su uso en nuestro fichero de inicio hace que se
actualice y se mantenga actualizado. Este paquete funciona en
conjunción con otros que ya tienes instalados como flymake,
yastnippets, eldoc, xref o project.
(use-package eglot-java :defer t :after eglot)
Al instalar este paquete cuando lo inicies por primera vez realiza
también la descarga del servidor LSP correspondiente. Si ya lo
tienes instalado, conviene que leas la documentación y que
proporciones un PATH válido para evitar que la realice.
No hay mucho más que detallar, a partir de ese momento lo único que
debes hacer es proporcionar un hook para que al abrir el modo para
Java se active también el eglot-java-mode. Y algunas combinaciones
de teclas para tener todas las funcionalidades a mano.
(add-hook 'java-mode-hook 'eglot-java-mode) (with-eval-after-load 'eglot-java (define-key eglot-java-mode-map (kbd "C-c l n") #'eglot-java-file-new) (define-key eglot-java-mode-map (kbd "C-c l x") #'eglot-java-run-main) (define-key eglot-java-mode-map (kbd "C-c l t") #'eglot-java-run-test) (define-key eglot-java-mode-map (kbd "C-c l N") #'eglot-java-project-new) (define-key eglot-java-mode-map (kbd "C-c l T") #'eglot-java-project-build-task) (define-key eglot-java-mode-map (kbd "C-c l R") #'eglot-java-project-build-refresh))
Antes señalé cómo se podía compilar desde la línea de comandos
utilizando gradle. No estaría de más que instalaras también el
paquete flymake-gradle. Para llamar la compilación desde Emacs
teniendo eglot-java activado debemos llamar a
eglot-java-project-build-task, con la combinación C-c l T que
vemos en las definiciones de teclas anteriores. Cuando pregunte qué
tarea debe hacer, añadimos la misma coletilla que se añadía en la
línea de comandos: assembleDebug, assembleRelease... etc.
Entre la documentación recomiendan la instalación de un depurador de
Emacs llamado dape, que, como he dicho antes, no he
probado. Cuando lo haga, ya comentaré por aquí la experiencia.
(use-package dape :defer t)
Conclusiones
He instalado eglot-java más con la intención de probarlo y escribir
este artículo que con la de dejarlo. Ya he comentado en este blog lo
poco que me gusta LSP y todo lo relacionado con él. Sin embargo, son
muchos los que me preguntan por ello y cómo configurarlo. Quieren
tener «la mostra» pero dentro de unos límites y no les culpo. Lo
que me gusta de Emacs es que todo es uniforme, todos los paquetes
funcionan de manera similar y se complementan, meter una herramienta
extraña para hacer lo que ya hacen otros paquetes, meterla con
calzador, depender de terceros, para que acabe utilizando los mismos
paquetes que ya están disponibles para Emacs me parece un
despilfarro de recursos, pare eso utilizas esos paquetes directamente
y te evitas LSP. Pero bueno, mantendré durante un tiempo eglot
para probarlo a fondo y si fuera el caso, ya os contaré cómo sale
todo.
Notas al pie de página:
Con mi socio hemos dado en llamarlo «la mostra» por la gran cantidad de recursos que se necesitan para ponerlo en marcha.
Comentarios