Aprovechando la tesitura de los cambios, ─y puesto que algunos me habéis preguntado cómo me las apaño para levantar un servidor web con el editor─, os cuento cómo lo hago con las pruebas.

En este caso, para toquetear el css y ver cómo van reaccionando los distintos parámetros en la página, sin estropear nada de la actual, lo que hago es copiar algunos ficheros en otro directorio. Me explico:

1. Tengo copia local del blog para hacer pruebas en el directorio ~/public_html y cuando publico algo, org-static-mode lo guarda ahí. Hago pruebas de visualización en local, corrijo errores y cuando creo que está todo correcto lo subo a su sitio en Internet con FileZilla.
2. Para no estropear ese directorio y terminar arrastrando demasiada basura al sitio correspondiente lo que hago es copiar algunos directorios y ficheros para las pruebas. Para este caso:
   • ~/public_html/medios, donde se encuentran agrupados css, fuentes, img y js que son las cosas necesarias para el diseño de la página.
   • Algunos ficheros html, como el index.html y los últimos artículos con su estructura de directorios para interactuar un poco en las pruebas.
3. Todo eso va copiado a un directorio que se puede llamar, por ejemplo, ~/proyectos/cambios-web que será donde tengamos que levantar el servidor de pruebas:
   • M-x httpd-serve-directory tras pulsar <RET> le decimos nuestro directorio de trabajo, en el ejemplo ~/proyectos/cambios-web.
   • Y por último, levantamos el servidor con M-x httpd-start

4. Abrimos el navegador con la dirección http://localhost:8080. Por defecto el puerto donde se sirve el contenido es 8080. Si quieres cambiarlo, digamos por el 6969, tienes que evaluar la expresión:

   (setq httpd-port 6969)
   

Posteriormente el trabajo consiste en ir haciendo las modificaciones que consideramos oportunas e ir actualizando la visualización pulsando <F5> en el navegador. Algunas veces, incluso se pueden ir modificando los pichorros en las herramientas de desarrollador, C-s-i, en el navegador para probar directamente y posteriormente pasar esos parámetros al código.

El servidor lo podemos parar con el comando M-x httpd-stop. Tampoco quiero enrollarme mucho sobre el tema. Si te parece interesante y te gustaría saber un poco más sobre cómo trabajar en Emacs para la web me lo dices por los canales habituales y dedico un artículo completo con todo lujo de detalle al tema.

Hay un paquete para trabajar con Rust en Emacs que se llama rustic. Ya os advierto que más rústico y rural que yo no lo hay. La instalación es como siempre sencilla:

M-x package-install <RET> rustic <RET>

En la configuración sólo añadí un escueto:

(require 'rustic)

Sin embargo, cada vez que abría un fichero .rs el modo rustic preguntaba por lsp³. Como sabéis, lsp es un modo que permite a Emacs convertirse en un IDE moderno integrándose con otros paquetes como company, projectile o flycheck. Hasta ahora no había probado lsp porque la otra vez que lo intenté, resultó en un enlentecimiento casi desesperante del editor y no le vi la utilidad.

Supongo que aquel problema sería con respecto al modo de edición, que en aquella ocasión era Python, esta vez, siguiendo los pasos de configuración, que no han sido muchos, la cosa va un poco mejor. Tarda en arrancar el Emacs, ha duplicado el tiempo de carga y se sitúa en tres segundos y medio, más o menos. Cuando abro algún proyecto de Rust también tarda en cargar el fichero de código mientras levanta el servidor y se conecta, pero luego funciona con soltura.

El problema creo que viene del montón de dependencias que tiene lsp-mode cuando lo instalas. Tienes que instalar también otros paquetes, como lsp-ivy (o lsp-helm), company-lsp, lsp-ui, dap-mode y también parece que es recomendable instalar eglot. Después de intentar configurarlo todo he ido renunciando a algunas cosas, aunque mantengo los paquetes instalados por compatibilidad, lo demás que uso viene en el código:

(require 'lsp-mode)
(add-hook 'rust-mode-hook #'lsp)
(add-hook 'rust-mode-hook '(lsp-install-server 'rust-analyzer))
(add-hook 'rustic-mode-hook 'englot-ensure)

El paquete dap-mode⁴ he sido incapaz de hacerlo funcionar, pero puesto que es un paquete de depuración tiro del clásico gdb de toda la vida para hacer lo mismo.

Y si no funciona el chismático de depuración moderno, pues habrá que tirar del clásico. Es un poco menos vistoso pero funciona con solvencia. El problema es que al no estar integrado en el IDE tienes que hacer un par de cosas más tú a mano.

Si ya has utilizado antes Emacs como un entorno gráfico de depuración con gdb te puedes saltar éste punto. Si no lo has hecho, voy a dar unas breves pinceladas de cómo lo hago yo. Si crees que es interesante el tema, ya me lo dices y prometo que escribiré un artículo completo sobre el tema.

Arrancar gdb en Emacs es sencillo: M-x gdb, nos pregunta por el comando que utilizará, que por defecto es gdb -i=mi y obtendremos una ventana parecida a:

Es un buffer que se llama gud y que muestra el prompt del depurador gdb. Si estamos acostumbrados a utilizar gdb desde la línea de comandos lo podemos hacer aquí directamente. Si os sale una ventana divida en varios buffers, es porque tenéis configurada la variable gdb-many-windows a t.

En todo caso, si no tenéis esa variable activada y queréis activar los buffers de visualización, sólo tenéis que teclear M-x gdb-many-windows y os aparecerán.

De momento, hemos cargado el depurador pero en vacío y no hay un programa que depurar. Para hacerlo, nos vamos al buffer gud, si no estamos en él, y tecleamos file nombre-del-ejecutable. En este caso yo he tecleado:

file ~/proyectos/rust/rustracer/target/debug/rustracer

Debería abrirnos el fichero principal de código también, pero si no es así, lo abrimos nosotros... La pantalla quedaría así:

Ahora sólo necesitamos hacer que nuestro programa se pare en algún sitio durante la ejecución para poder inspeccionar cómo evoluciona. Establecer un punto de parada o breakpoint podemos hacerlo de varias formas. Yo utilizo dos, principalmente. Una es teclear en el buffer gud el comando break NN donde NN es el número de línea donde quiero establecer el punto de parada. La otra es ir al buffer donde se muestra el código fuente, ir a la línea donde quiero hacer la parada y llamar al comando gud-break.

Sea cual sea el método empleado, podemos observar que nos señala gráficamente el punto de parada con un círculo rojo la línea donde lo hemos establecido y además aparece en la lista del buffer de breakpoints, abajo a la derecha.

El resto de acciones las podemos llevar a cabo manualmente desde gud o utilizar la barra de botones, que es muy similar a cualquier otra herramienta de depuración.