Hay que contar que tengo bloqueadas (inhabilitadas) todas las aplicaciones de Google. Algunas sustituidas por otras libres descargadas de F-Droid y otras simplemente ignoradas, inhabilitadas (y bien que se queja el cacharro de que tengo aplicaciones importantes paradas... en fin).

Espero que a estas alturas hayamos pasado la mala racha de viajes continuos y enfermedades varias, para poder dedicarme a otras cosas. De momento, como siempre, seguiré con mis trasteos e iré, poco a poco, avanzando en la realización de la historia o el libro-juego. No me he puesto plazo para publicar lo que será un epub con el contenido. Según cómo quede la historia, incluso me planteo gastarme algo de dinero en algún(a) ilustrador(a) que me haga unas pocas ilustraciones para acompañar al texto. Pero eso ya cuenta en el ámbito de los futuribles.

La ilo havas ankaŭ tekstan babiladon. Tiu kiu vi skribos, iros al kanalo kien vi enestas tiel, kiel voĉe.

La Mumblea servilo estos daŭre starigita. Vi povas uzi kiel vi plej ŝatos. Ĝian celon estas, certe, por ludi, sed ĝi estas sendependa servilo, kaj oni povas uzi ĝin ankaŭ por renkontiĝi kaj interparoli esperante se vi ne bezonas montri bildojn aŭ la intervidado.

Mi rekomendas la uzon de tiu ilo, ĉar la babilado en Luanti ne estas ĉifrata kaj transiras la reton klare montrata, ne nur por la ludantoj konektataj, sed ankaŭ por tiuj, kiuj povas interkapti la konektadon.

Se vi volas privatecon, uzu tiun ilon por paroli voĉe.

Ĉar la servilo estos daŭre starigita, kiel mi diris antaŭe, oni povas uzi por renkonti aliajn esperantojn kaj por praktiki la paroladon, sen ludi. Sed por tiuj aferoj mi petas, ĉar la unua celo de la servo estas por la ludantoj, ke vi kreos nedaŭran kanalon por ne ĝeni la aliajn uzantoj kiuj povos eniri la ludon aŭ krei sian propran kanalon. La kanalojn estos publikaj por tiu, kiu eniros la servon, do oni povas eniri iu ajn, memoru ke vi povas esti aŭskultata ne nur por tiuj, kiuj vi esperas².

Pro vi estas tiuj serviloj. Se vi havas sugestiojn aŭ problemojn elsendu retmesaĝon al retpoŝto esperanto ĉe nueva-actitud.org. Ankaŭ skribu nin se vi volas partopreni en la laboro pri la subtenado de la ludojn kaj la servilojn.

La ludado estas libera (ene de la respektanta kutima agado) kaj tute senpaga. Ni ne petos al vi monon pro neniu servo, kiun ni elstarigis. Do, ni petas al vi, respektu nian laboron kaj ne insidos la ludon de la ceteraj uzantoj.

En resumen: Si no te gustan estos temas, no leas estos artículos. Si sólo buscas documentación sobre Emacs, te recuerdo que Emacs provee un completo manual de uso y también otro completo manual de programación. Todos los artículos que he escrito, y los que escribiré, sobre Emacs están sacados de esos manuales o de la documentación del paquete concreto sobre el que trata el artículo. Seguro que tú también puedes, incluso mejor que yo, extraer esa información de esas fuentes.

Este blog es mi blog. Trato temas sobre tecnologías, sobre psicología, sobre juegos, sobre Esperanto... temas que a mí me interesan. Y además, está escrito sin ánimo de lucro, ni siquiera de reconocimiento, no busca ser leído por nadie en concreto, salvo por mí, pues suelo usarlo con frecuencia para recordarme a mí mismo cómo hacer ciertas cosas. Está abierto al espacio público, porque algunas cosas pueden ser útiles a otras personas, pero no necesito lectores, no verás anuncios, ni ningún otro sistema de monetización estándar. Este es un espacio libre, donde ejerzo mi libertad de escribir sobre lo que quiero, desde mi punto de vista, desde el respeto. Si te gustaría que fuera de esta o de aquella manera, no necesitas contármelo a mí: escribe tú en el tuyo según tus gustos y monetiza lo que hagas como tú quieras. No apeles a una avaricia que no tengo para influir los temas que debería tratar.

El primer post de Notxor tiene un blog se publicó el 1 de febrero de 2016, este próximo febrero, el blog cumplirá 10 años. En los casi 10 años que lleva en funcionamiento, el sistema de donaciones ha recaudado la magnífica suma de 5€ en total⁴. Antes escribí en otro blog, que se perdió en las memorias del tiempo y que en sus seis años de funcionamiento recaudó la abultada suma de 0€. Si mantengo el blog, es evidente que no es por razones económicas. De él sólo obtengo facturas y gastos.

Hace bastante cerré los comentarios del blog, entre otras cosas, para evitar mensajes de trolls dispuestos a criticar hasta lo no criticable. Aunque el motivo fundamental fue que hubo ataques malintencionados, de script kiddies⁵, que me hacían tener que estar limpiando el espacio de comentarios varias horas al día. No voy a abrirlos porque lo pida nadie o porque harían más monetizable el blog, no insistas.

Ha sido un interesante repaso de los pocos conocimientos que tengo de Smalltalk. El cacharreo ha sido interesante. Por lo que he visto Morphic¹ es ligeramente diferente a como lo recordaba de cuando utilicé Squeak.

El objetivo ahora es conseguir hacer algún proyecto interesante, quizá deba darme un repaso a los dos librillos que tienen sobre la UI para manejarme con más soltura.

¡Seguiremos informando!

Después de tantos años he vuelto a trastear con Smalltalk, lo confieso. Como he dicho, llevo semanas en ello con Cuis-Smalltalk https://cuis.st/ un Smalltalk que conocía ¹. Concretamente siguiendo el libro The Cuis Book https://drcuis.github.io/TheCuisBook/, sobre el cual me estoy tomando la tarea de traducir al españolMis avances, aunque lentos, los podréis encontrar en este enlace.². En principio, sería para uso personal, pero si al final queda bien, se podría enviar a los autores del libro, en formato texinfo para que puedan añadirlo al repositorio. En fin, ya se verá.

Lo que me ha hecho retomarlo es el mismo sentimiento que me llevó a él en un primer momento. Proviene de una época donde se pensaba en la tecnología como un complemento a lo humano. El sistema de Smalltalk nació con la idea de ser un apoyo, una ayuda que le facilitara a las personas expresar sus pensamientos e ideas. Ahora nos venden que el futuro es que las máquinas piensen por nosotros. En algún momento, está claro, que perdimos el norte. Cuando Alan Kay decía que «una computadora sólo es un instrumento cuya música son ideas» o que son «bicicletas para la mente», estaba poniendo en el centro el desarrollo humano, las ideas humanas, no las de la máquina. Pero me estoy adelantando, regreso a los orígenes a ver si consigo hacerme entender.

Cuando la electrónica se desarrolla y se generan los primeros inicios de la computación. El pensamiento que regía el proceso central era el pensamiento humanolo sigue siendo, a pesar de que haya mucha gente empeñada en vendernos humo con la IA., las máquinas se limitaban a procesar muchos datos más rápido de lo que podemos hacer las personas. Sin embargo, ya se planteaban maneras en que se podrían utilizar esas máquinas para ayudar al desarrollo cognitivo humano.

Para esto, podemos encontrar varios predecesores de esto, incluso antes de la computación^{3, 4}, durante los años 40 del siglo pasado.

Durante esos años y posteriores, la psicología desarrollaba su teoría constructivista del aprendizaje⁵, cuyos postulados nacen de los trabajos de algunos exponentes principales como Lev Vygotski, Jean Piageten realidad era biólogo, Seymur Paperfue un matemático pionero en la IA, creador del lenguaje Logo. o Albert Bandura, por poner sólo unos ejemplos. No voy a entrar tampoco en profundizar en esta teoría, ni en las polémicas de seguidores y detractores que aún colean en el ámbito de la psicología. Aún recuerdo una conferencia de Paul Watzlawick, sobre el arte de amargarse la vida durante mis años en la Universidad.

Lo menciono porque el desarrollo de Smalltalk está imbricado con esta teoría y es un intento de proporcionar una herramienta que ayude al desarrollo cognitivo humano. Especialmente para Alan Kay ^{6 , 7 , 8 , 9}.

Pero avanzando un poco más, podemos encontrar algunos principios de diseño interesantes, según los plantea Dan Ingalls¹⁰. Para empezar define el propósito del lenguaje como un marco para la comunicación. Para la comunicación interpersonal, no sólo la comunicación de ordenadores o sistemas dentro de un ordenador.

También, en su principio de metáfora única, propone que un lenguaje debería ser diseñado alrededor de una única potente metáfora que se pueda aplicar en todas las áreas. Por ello, en Smalltalk, todo es un objeto que interactúa con los objetos de su entorno enviándoles mensajes. A partir de esta metáfora se construye todo. Ocurre, en ese sentido podríamos pensar lo mismo sobre Lisp, donde todo son listas, los datos y el código pertenecen a la misma metáfora. Es decir, los sistemas deberían simplificarnos todo lo posible la manera en que pensamos sobre ellos, especialmente en los sistemas complejos.

Además, establece un principio, que desde mi punto de vista está muy relacionado con los principios del software libre. Este es el principio reactivo, que afirma que todo componente accesible debería estar presente de manera comprensible para el usuario de manera que le permita manipularlo y observarlo.

Pero de manera más general, lo que más me atrajo en su día, el autor lo expresa en su primer principio, que viene a decir que «si un sistema debe servir para la creatividad humana, debería ser perfectamente comprensible para una persona».

Hasta ahora había trabajado principalmente con los tres Smalltalk que nombré en el artículo anterior. Cuis lo conocía de nombre, pero nunca me había puesto a trabajar con él. Lo concebía como un fork del original Squeak y, puestos a trastear, hasta ahora me había quedado con el original.

La historia del software pasó por encima a Smalltalk, que nació con la pretensión fundamental de ampliar las capacidades humanas en una época donde el hardware estaba tan limitado que cerró las posibilidades del ese software. La tecnología se metió en una vorágine evolutiva primando eficiencia, velocidad, máquina sobre lo humano y Smalltalk no se destaca en esos aspectos. Aunque algunos de esos sistemas lo intentaron, fueron rápidamente adelantados por otros lenguajes más complicados, más confusos, pero más «eficientes».

Estos días he vuelto a trastear con Cuis y me vuelvo a sentir implicado con él. Cuis es un intento de prolongar esa filosofía que creó Smalltalk, la de poner en el centro el pensamiento humano y continuar el legado del Smalltalk-80. Más allá de las demás consideraciones he vuelto a encontrar un poco de paz en mi confuso cerebro. Quizá porque es realmente un sistema de programación orientada a objetos y no un engendro con clases, que también aprovecha algunos principios de la programación funcional, maneja las colecciones de manera clara y sencilla, como lo podría hacer Lisp. El código externo no modifica las variables, es el propio objeto el responsable de su estado. Los elementos del lenguaje son mínimos: objetos, menajes y bloques de códigoque consisten en más objetos enviándose mensajes. Todo se monta así, buclesel resultado de enviar los mensajes adecuados a un número entero, control de flujoel resultado de enviarle mensajes a un objeto de clase Boolean. Además cuenta con un entorno completo que permite no sólo programar, sino también el acceso completo al lenguaje, ver cómo está implementado, herramientas para el depurado, las pruebas unitarias, un completo sistema gráfico de presentación de la información. Todo ello accesible, programable, modificable.

He podido percibir también, que Cuis elimina la necesidad de algunos aspectos complejos de su sistema padre Squeak. La exploración se me está haciendo más sencilla. Aunque tampoco puedo afirmar que sea por esto, porque siempre es más sencillo retomar algo ya conocido que iniciarse de cero. Es posible que me autoengañe y perciba una mayor sencillez porque lo entiendo mejor por mis conocimientos previos y no porque lo sea realmente. Pero esa sensación la tengo.

En fin, estos días he vuelto a pensar en lo errado del desarrollo de software y cómo las buenas ideas, aquellas que ponían al ser humano en el centro del proceso, han sido desplazadas por otras que ponen la eficiencia en tiempo y dinero. Más últimamente con la IA, que nos promete que el futuro de las máquinas es sustituir el pensamiento humano, no ayudarlo a formarse, a evolucionar sino eliminarlo por completo. ¿De verdad alguien cree que no vamos a necesitar pensar, tener ideas y desarrollarlas?

Seguramente has oído hablar de Smalltalk. Posiblemente, y puesto que uno de los nichos donde se ha quedado encerrado es el educativo, si has estudiado programación, incluso puede que lo hayas estudiado. Pero no trato de hacer una presentación aséptica, completa y exhaustiva del lenguaje y sus herramientas, sino que voy a dar mis puntos de vista, subjetivos, evidentemente, sobre este asunto. Me gustó su sencillez: en la imagen de arriba tenéis resumida todos los elementos de la sintaxis del lenguaje en una postal.

Cuando me llegó información concreta sobre Smalltalk ya conocía otros lenguajes y programaba con cierta soltura con algunos de ellos, bajo la égida de la POO². En general, la POO me parece una buena abstracción como psicólogo³, aunque para resolver problemas puede haber otros procedimientos tan válidos o, incluso, más eficientes. De hecho, en líneas generales, considero que la POO puede también entorpecer u ofuscar una solución, cuando las clases empiezan a ser más etéreas y menos tangibles. Los conceptos, menos tangibles, o más abstractos si lo prefieres, son más complicados de manejar por la mente humana y, por tanto, de llevar a una estructura virtual, paralela en POO.

Éste enfoque, Smalltalk lo resume en dos aspectos: cosas y acciones, nombrándolas como objetos y llamadas⁴. En este lenguaje todo dato es un objeto, una clase es un objeto, y todo lo que no es un objeto, es una llamada. Por ejemplo, los operadores aritméticos son llamadas definidas en la clase numérica correspondiente, igual que las funciones trigonométricas. Llegando al extremo, de que no hay palabras clave como if, operadores o bucles como for. Pero en la clase Boolean encontrarás llamadas como IfTrue:, IfFalse, or: o and:, por poner algunos ejemplos. La estructura no cambia y se puede resumir, en general como:

objeto llamada [parámetros]

El problema de este enfoque es que necesitarías muchas horas de trabajo para levantar cualquier tipo de entorno que resuelva algún problema sólo con esas premisas y partiendo de cero. Para ello, otra característica de Smalltalk es la cantidad de código que ya nos proporciona hecho, funcionando y probado y, por tanto, podemos encontrarnos dos partes bien diferenciadas de Smalltalk: la máquina virtual (vm) y la imagen⁵. La vm suele coincidir con un ejecutable, que dependerá de cada sistema operativo, pero cuya función es hacer que los objetos contenidos en el código y las librerías dentro de la imagen cobren vida y se envíen mensajes unos a otros para funcionar.

Este modelo es su principal fuerza y su principal desventaja. Por un lado, tenemos que una imagen es una base de datos del estado de los objetos que contine. Cuando guardamos una imagen, guardamos en un archivo de disco estático el estado de todos los objetos que contiene nuestro entorno de trabajo. Por el otro, las imágenes tienen bastante peso y son un inconveniente en el proceso de distribución de nuestra aplicación. Es decir, nos da resuelto el problema de la serialización del contenido, pero a cambio de dificultarnos la distribución.

Cuando está en funcionamiento se convierte en un sistema REPL⁶ con esteroides. Mientras estás programando puedes evaluar cualquier código, no hay nada oculto en librerías, todo está a la vista. Puedes crear clases, dotarlas de nuevos mensajes, modificar el código que ya existe evaluando su adecuación al proyecto sin detener en ningún momento el proceso. Si se produce algún error, aparecerá un mensaje junto con una ventana de depuración, donde podrás modificar el código o escribir nuevo sobre la marcha. Puedes inspeccionar cualquier objeto del sistema e incluso modificarlo mientras se ejecuta. Es el sistema más interactivo y flexible que he utilizado jamás y este fue el principal motivo que me enganchó durante aquellos años.

Éste fue mi primer entorno Smalltalk, aunque no llegué a él buscándolo como herramienta de programación, sino como herramienta educativa. En aquel entonces me dedicaba a dar clases y Squeak fue un juguete muy útil. Por él me metí en el mundo de Smalltalk, aprendí el lenguaje y algunas cosas más sobre programación en general.

Cuando empecé a trastear con él, lo hice por los eToys. En el entorno de Squeak puedes hacer cualquier dibujo a mano alzada (un eToy) y luego programarle comportamientos como que se desplace, que rote, que cambie de color, etc. Puedes ponerle sensores que detecten otros eToys y que interactúen entre sí, etc. Si has trabajado alguna vez con Scratch⁷, ese sistema basó su idea en esta herramienta.

Los menús, herramientas de programación y demás elementos se articulan desde un sistema de ventanas Morphic, basado en Self. Por lo demás, es un Smalltalk completo y como tal todo el sistema se puede visualizar (y modificar) en el Browser. Su principal impulsor fue Alan Kay, uno de los creadores de ST-80, y por tanto mantiene herramientas como el famoso Browser para visualizar el código mediante el árbol de paquetes, clases, protocolos y llamadas.

Cuando yo empecé a trastearlo todavía se utilizaban en el código Smalltalk el símbolo ← para hacer las asignaciones y ↑ para hacer una devolución desde una llamada⁸. La separación del código entre clases (en el archivo .changes) venía delimitado por un carácter de salto de página y de fin de archivo para separar paquetes. Esto hacía complicado la edición en otros editores que no fueran los propios del entorno.

Al poco tiempo apareció GNU Smalltalk como herramienta de scripting y por tanto debía utilizar una codificación ASCII sin caracteres no imprimibles. Squeak también comenzó derivó a utilizar el código más de texto plano.

En resumen: me lo pasé muy bien con Squeak. Mis alumnos aún más. Recuerdo aún algunos ejercicios, el primero consistía en dibujar un eToy similar a un coche y otro similar a una carretera y programar el primero para siguiera el segundo. Recuerdo otro ejercicio donde programábamos una caja de Skinner para ilustrar los distintos tipos de aprendizaje animal, con sus refuerzos positivos y negativos mediante un esquema de palancas, sonidos y luces simuladas con eToys.

Pharo se inició como un fork de Squeak. El objetivo perseguido, y conseguido desde mi punto de vista, era proporcionar un entorno más profesional para programar en Smalltalk. Por tanto, eliminó los eToys y le dio un aspecto más formal en la interface con Morphics.

Su mayor aportación, desde mi punto de vista fue el desarrollo de las herramientas Monticello y Metacello⁹, que se adoptaron también rápidamente en Squeak. Proporcionando un sistema de control de versiones y facilitando el trabajo en equipo.

Por otro lado, al ser Pharo un fork de Squeak su imagen sigue siendo heredera en su kernel más profundo del estándar ST-80 que definió Smalltalk a finales de los años 70. Este kernel lleva funcionando y depurándose muchos años, por lo que se puede confiar en la estabilidad y afinación del sistema.

A la vez que se desarrollaba Pharo, aparecieron entornos web y de servidor como Aidaweb o Seaside. Que permiten desarrollos de aplicaciones concurrentes y accesibles sin necesidad de instalar ninguna infraestructura.

Aunque Squeak siempre será mi favorito, por haber sido el primer entorno Smalltalk libre con el que trasteé. Si estás pensando en un entorno más profesional, Pharo es el más aconsejable. Especialmente por su herramienta pharo-launcher.

Esta herramienta nos permite descargar distintas imágenes y máquinas virtuales. De esta manera, podemos gestionar fácilmente los proyectos aún con versiones de Pharo antiguas.

Smalltalk/X es un entorno Smalltalk completo desarrollado por la empresa alemana eXept software AG y que se distribuye gratuitamente, sólo hay que registrarse como usuario. En su día lo estuve, pero el correo electrónico con que lo hice ya no lo tengo y por tanto he perdido la posibilidad de volver a descargarlo sin volver a registrarme. Podría hacerlo de nuevo, sí, pero a estas alturas no creo que lo utilizara mucho y puede la pereza. Además, cuando me registré eran años en los que la paranoia no estaba tan asentada como ahora 😜.

Pero también he encontrado un fork que se puede descargar libremente desde https://jan.vrany.io/stx/. Así que me puse a probarlo y he comprobado que faltan algunas partes (supongo que las propietarias) y al intentar acceder a ellas lanza un inevitable error.

Lo primero que salta a la vista de esta herramienta es que las ventanas de las herramientas son independientes. En los dos entornos anteriores no era así, porque Squeak nació con pretensiones de sistema operativo para el proyecto Dynabook de Alan Kay. Integraba herramientas de gestión de archivos, sonido, gráficos, presentación, etc. Es decir, todo en una ventana con ánimo hacer de escritorio.

Otro de los puntos interesantes de Smalltalk/X, al menos en su día, era la facilidad para adecuar la interface imitando las ventanas del Sistema Operativo anfitrión y el que detecte el idioma configurado en el mismo para mostrar menús y widgets.

Pero la ventaja principal, por lo menos desde mi punto de vista, cuando lo llegué a utilizar de manera profesional, es que puede generar ejecutables independientes y evita el modelo de vm+imagen de los otros sistemas Smalltalk. Además podías escribir código C directamente en las clases y la integración con C era fácil y fluida. He visto que el fork que enlazo también tiene soporte para Java.

Llegué a Smalltalk/X un poco de rebote. Me apunté, joven yo, a una de esas, ahora llamadas, startups que prometen mucho y pagan poco. La idea inicial era desarrollar una aplicación de escritorio. El jefe prefería éste sistema a Java. La historia es larga y con ramificaciones legales que no vienen al caso. El asunto es que, conseguimos poner en marcha una beta del programa y comenzar con las pruebas en producción con algunas pequeñas empresas cliente. Durante las primeras pruebas se llegó a la conclusión de que se necesitaba un acceso concurrente y aprovechando que teníamos funcionando de manera suficientemente estable el modelo de negocio en Smalltalk/X, lo pasamos fácilmente a Pharo sobre un servidor web Aida. En un par de meses conseguimos hacer el cambio y conseguir otra decena de empresas cliente... todo parecía ir correctamente hasta que el jefe recibió una oferta y vendió la empresa. Los que la compraron ni habían oído hablar de Smalltalk ni les importaba, nos despidieron a todos de un día para otro, y se pusieron con una evolución que creían que podían hacer en tres días con PHP. Y así terminó mi única incursión profesional programando en Smalltalk. A la semana de ser despedidos nos llamaron para que regresáramos a mantener lo que ya teníamos funcionando mientras hacían su aplicación. Yo no regresé, en ese tiempo era un segundo trabajo y no lo necesitaba para pagar la hipoteca. Luego me enteré de que no volvimos nadie del equipo ST, hubo bastantes reclamaciones y tuvieron que pagar varias indemnizaciones y la empresa quebró.

Las cosas han evolucionado bastante desde que abandoné Smalltalk. Por ejemplo, en el aspecto del trabajo en equipo. Cuando lo dejé existía Monticelo y nada más. Ahora veo que estas tres herramientas cuentan con soporte para Git.

Los sistemas se han mostrado bastante ligeros. No puedo asegurar si es por una mejora en la ejecución de Smalltalk o que ahora mi máquina es más capaz, pero la velocidad percibida es bastante más fluida de lo que la recordaba. Pero no debe ser sólo eso: en su día Smalltalk/X era más ágil que Squeak o Pharo, pero esta vez, éstos dos se han mostrado bastante más rápidos, especialmente Squeak.

En estos momentos había pensado darle otro tiento a Pharo, aprender cómo va el tema de gestionar respositorios Git y hacer algún ejercicio sencillo. Ahora mismo supongo que me costará más retomarlo, mis esquemas mentales se han ido orientando más la programación funcional que a la POO, pero supongo que todo es ponerse. Aunque a estas alturas tampoco garantizo que llegaré a nada concreto, lo mismo me empieza a aburrir a los dos días como todos los proyectos que empiezo últimamente.

Si ya estás utilizando algún paquete experimental cargándolo desde fuera de la lista de MELPA, simplemente tendrás que añadir la URL al repositorio de código en el código de use-package. Si no lo estás haciendo, antes debes descargar el paquete request para poder hacerlo. El código, como se muestra en las instrucciones de instalación quedaría así:

(use-package request)
(use-package org-social
  :vc ( :url "https://github.com/tanrax/org-social.el"
        :rev :newest))

Si recibes algún error al abrir Emacs después de haber escrito esas líneas, es posible que esté intentando cargar el paquete org-social antes de que esté instalado request. Cierra Emacs y vuelve a abrirlo.

El código se actualizará automágicamente, pero comprobará en cada arranque si está actualizado, lo que ralentizará un poco el inicio. Lo podéis evitar prescindiendo de automatismos y descargando el código por vuestra cuenta. Para configurarlo así tenéis que poner un enlace al directorio donde lo hayáis descargado y llamarlo de forma directa con la forma require habitual. Para ello utilizad el código:

(add-to-list 'load-path "/path/al/paquete/org-social.el")
(require 'org-social)

Con esto, ya has terminado con lo mínimo imprescindible para tener el paquete instalado y funcionando. Sin embargo, aún no es de mucha utilidad y seguramente no podrás ver nada.

Configurarlo en Emacs, como habéis visto, es muy sencillo y lo haces en dos patadas, pero necesitas algunas condiciones previas:

1. Crear un archivo org con la información.
2. Subirlo a un servidor HTTP.
3. Interactuar con alguien.

Ahora toca configurarlo para su funcionamiento.

Es complicado encontrar gente en esta red. Primero porque acaba de nacer prácticamente y segundo, porque es una red descentralizada en la que cada uno tiene su archivo y no hay más infraestructura que facilite la interacción. Para minimizar un poco este hecho, en la web de org-social hay un archivo txt con un listado con las URL de algunos usuarios. He tomado esa lista de usuarios y he añadido a la cabecera de mi archivo social.org los siguientes follows:

#+FOLLOW: https://andros.dev/static/social.org
#+FOLLOW: https://rossabaker.com/social.org
#+FOLLOW: https://omidmash.de/social.org
#+FOLLOW: https://johnhame.link/social.org
#+FOLLOW: https://eoin.site/social.org
#+FOLLOW: https://adsan.dev/social.org
#+FOLLOW: https://emillo.net/social.org
#+FOLLOW: https://cmdln.org/social.org

De momento los sigo todos mientras voy descubriendo otros usuarios y amplío el espectro y temáticas. Si quieres seguirme a mí añade en tu cabecera el código:

#+FOLLOW: https://notxor.nueva-actitud.org/social.org

No voy a darme de alta en ese archivo, al menos todavía. Por varios motivos:

1. Para añadirte tienes que hacer un pull request a dicho fichero en Github. Creo que hace como 10 u 11 años que no uso dicha plataforma y prefiero seguir sin usarla.²
2. Todos los posts, de la gente que está en la lista, están en inglés, lo mismo les mato alguna neurona posteando en español o les frío medio cerebro cuando lo haga en Esperanto.
3. Aún no estoy seguro de cuánto usaré esta red social o si la terminaré abandonando, estoy de pruebas.

Los seres humanos somos seres sociales que necesitamos interactuar en comunidades para desarrollarnos plenamente. La expresión de nuestra individualidad no es individual, sino que se manifiesta dentro de la comunidad. En esta red social veo ambas vertientes complementándose: puedes interactuar con la comunidad, pero mantienes tu individualista archivo social.org bajo control.

Tus datos son tuyos y los tienes bajo control. Para establecer contacto, o más bien, para permitir que establezcan contacto contigo, debes situar dicho archivo org en un lugar accesible desde la web. Una solución sencilla y práctica. Cualquier servidor HTTP te servirá. En mi caso, puesto que tengo el blog, lo más rápido es ponerlo en el directorio raíz del mismo.

Las opciones de momento son muy básicas, te permiten crear entradas, responder las de otra gente y poco más. Sin embargo, al hacerlo sobre un archivo org-mode te proporciona toda la potencia que tiene éste para interactuar con la información. Por esto, si org-mode no tiene límites, org-social tampoco los tendrá.

Como conclusión, y por lo que veo en las entradas de mi timeline, estamos en una red social un poco de nicho, especialmente de seguidores de Emacs y de Org. Tengo mucha curiosidad por ver cómo evoluciona.

Para aprender el lenguaje y sus interacciones, estando embebido en una aplicación escrita en otro lenguaje, necesitaba una aplicación que hospedara un intérprete de Lua para hacer funcionar algo. Debía ser una aplicación suficientemente compleja como para poner a prueba el asunto, pero que no me distrajera del objetivo último, que es aprender Lua y sus idiosincrasias.

Elegí un proyecto con el que estoy ya familiarizado, un raytracer. El objetivo es hacer una aplicaciónEn C. que genere una imagen que venga descrita en un script escrito en Lua.

El primer paso consistió en programar en Lua el mismo raytracer que se desarrollará en C hasta alcanzar un punto en que hubiera más de un objeto (en concreto dos esferas) y una abstracción de cámara para hacer la imagen. Además, también con el objeto de aprender, implementé un sistema de corrutinas que remedaban un proceso paralelo. En realidad, Lua no implementa ese paralelismo, por mucho que llame thread al proceso que realiza una corrutina, no es un hilo independiente. Me sirvió para aprender cómo gestionarlas y si lo necesitara más adelante, bastaría con lanzar la corrutina en un nuevo intérprete.

Llegados a este punto, me puse a desarrollar lo mismo en C. La primera impresión fue el cambio en velocidad. No quiere decir que Lua sea lento, sino que C es rapidísimo. Por poner un sencillo ejemplo:

El código en Lua:

local math = require("math")
local string = require("string")

local function main()
   -- Imagen
   local ancho_imagen = 256
   local alto_imagen = 256

   -- Render

   print("P3\n" .. ancho_imagen .. " " .. alto_imagen .. "\n255\n")

    for j = 1, ancho_imagen do
        io.stderr:write(".") -- muestra un punto por cada línea dibujada
        for i = 1, alto_imagen do
            local r = i / ancho_imagen
            local g = j / alto_imagen
            local b = 0.0

            local er = math.modf(255.99999 * r)
            local eg = math.modf(255.99999 * g)
            local eb = math.modf(255.99999 * b)

            print(string.format("%d %d %d", er, eg, eb))
        end
    end
    io.stderr:write(" Hecho.\n")
end

main()

Ejecución y desempeño:

time lua .ejemplo.lua > ejemplo_lua.ppm

________________________________________________________
Executed in  331.23 millis    fish           external
   usr time   69.97 millis    0.00 millis   69.97 millis
   sys time  260.53 millis    1.64 millis  258.89 millis

Si comparamos este código con el equivalente de C:

#include <stdio.h>

int main() {
  int ancho_imagen = 256;
  int alto_imagen = 256;

  printf("P3 %d %d 255\n", ancho_imagen, alto_imagen);
  for (int j = 0; j <= alto_imagen - 1; j++) {
    fprintf(stderr, ".");
    for (int i = 0; i <= ancho_imagen - 1; i++) {
      double r = (double) i / ((double) ancho_imagen - 1);
      double g = (double) j / ((double) alto_imagen - 1);
      double b = 0.0;

      int ir = (int) 255.9999 * r;
      int ig = (int) 255.9999 * g;
      int ib = (int) 255.9999 * b;
      printf("%d %d %d\n", ir, ig, ib);
    }
  }
  fprintf(stderr, "-> Hecho.\n");
}

Compilado, ejecución y desempeño:

gcc -o ejemplo_c ejemplo.c
time ./ejemplo_c > ejemplo_c.ppm

________________________________________________________
Executed in   15.85 millis    fish           external
   usr time   10.19 millis    0.00 millis   10.19 millis
   sys time    4.53 millis    1.48 millis    3.06 millis

________________________________________________________
Executed in  277.37 millis    fish           external
   usr time   17.41 millis    1.41 millis   15.99 millis
   sys time  260.06 millis    0.16 millis  259.90 millis

No le daré más vueltas de momento a estos temas, que dejaré para más adelante, porque puestos a mirar el asunto, añadí algún lenguaje compilado más, como nim y zig.

El proyecto de aprendizaje aún está en desarrollo y me estoy divirtiendo un montón con él. Si consigo una buena integración entre ambos lenguajes no me extrañaría que lo siguiera desarrollando un poco, para conseguir mayor complejidad. Me refiero a verdadera multitarea, más tipos de objetos que simples esferas, otros formatos de salida (PNG, JPEG...) y, en fin, un raytracer más completo.

Como he dicho antes estoy en fase de pruebas más profundas de eglot aprovechando este proyecto. Lo tengo activado tanto en Lua como C. Si tienes curiosidad por conocer qué configuración estoy usando, el código está en su repositorio: https://codeberg.org/Notxor/init-emacs.

En el caso del lenguaje C estoy probando las dos herramientas LSP que tengo disponibles: clangd y ccls. Ambos cuentan con paquetes propios para OpenSuse Tumbleweed y se instalan sin problemas. El primero viene integrado en los paquetes de desarrollo de clang y LLVM, y el segundo viene en un paquete aparte.

El desempeño de ambos es correcto, con sus puntos fuertes y débiles. Por ejemplo, la información que ofrece clangd me está pareciendo más completa, pero a cambio de tocar un poco más las gónadas con cosas que aparecen (y desaparecen) según le parece a él durante la edición. De vez en cuando, con el ánimo de probar ambos, cambio entre ellos y como resumen puedo decir que me gusta más ccls por su sencillez y por no molestarme con demasiados desplegables o introduciendo elementos visuales entre el código. Una costumbre que sí tiene clangd, que inserta visualmente en las llamadas a una función el nombre de los parámetros que se encuentran en su definición... es información relevante, pero me resulta incómodo leer el código así.

Como ya apunté antes, cuando me puse a trabajar con C, me encontré haciendo pruebas con distintos lenguajes Lua, C, Rust... y añadí también otro par de los lenguajes compilados: nim y Zig. ¿Para qué? Pues para probar, simplemente. Soy consciente de que estas pruebas no están optimizadas, es un bucle pequeño, por lo que no esperaba encontrar muchas diferencias entre ellos. Para comenzar, colocaré aquí el código.

Rust:

fn main() {
    // imagen

    let ancho_imagen: i32 = 256;
    let alto_imagen: i32 = 256;

    println!("P3 {} {} 255", ancho_imagen, alto_imagen);

    for j in 0..alto_imagen {
        eprint!(".");
        for i in 0..ancho_imagen {
            let r: f64 = (i as f64) / ((ancho_imagen as f64) - 1.0);
            let g: f64 = (j as f64) / ((alto_imagen as f64) - 1.0);
            let b: f64 = 0.0;

            let ir: i32 = (255.9999 * r) as i32;
            let ig: i32 = (255.9999 * g) as i32;
            let ib: i32 = b as i32;
            println!("{} {} {}", ir, ig, ib);
        }
    }
    eprintln!("->Hecho.");
}

Compilación con el comando:

rustc -o ejemplo_rust -O ejemplo.rs

Nim:

proc main():void =
  var ancho_imagen: int = 256
  var alto_imagen: int = 256

  echo "P3 ", ancho_imagen, " ", alto_imagen, " 255"

  for j in 0..alto_imagen-1:
    for i in 0..ancho_imagen-1:
      var r: float = float(i) / (float(ancho_imagen) - 1)
      var g: float = float(j) / (float(alto_imagen) - 1)
      var b: float = 0.0

      var ir: int = int(255.9999 * r)
      var ig: int = int(255.9999 * g)
      var ib: int = int(255.9999 * b)
      echo ir, " ", ig, " ", ib
main()

Compilación:

nim c --opt:speed ejemplo.nim

Zig:

const std = @import("std");

pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    const ancho_imagen: i32 = 256;
    const alto_imagen: i32 = 256;

    try stdout.print("P3 {} {} 255\n", .{ ancho_imagen, alto_imagen });
    for (0..alto_imagen) |j| {
        for (0..ancho_imagen) |i| {
            const r: f64 = @as(f64, @floatFromInt(i)) / (ancho_imagen - 1);
            const g: f64 = @as(f64, @floatFromInt(j)) / (alto_imagen - 1);
            const b: f64 = 0.0;

            const ir: i32 = @as(i32, @intFromFloat(255.9999 * r));
            const ig: i32 = @as(i32, @intFromFloat(255.9999 * g));
            const ib: i32 = @as(i32, @intFromFloat(255.9999 * b));

            try stdout.print("{} {} {}\n", .{ ir, ig, ib });
        }
    }
}

Compilación:

zig build-exe ejemplo.zig

Los resultado son los siguientes:

No son pruebas definitivas. Es decir, llama la atención que un lenguaje compilado, como Zig se vaya a los 3,14 segundos en la ejecución obteniendo peores resultados incluso que Lua.

Seguramente, cualquier lenguaje de esos puede compilarse más optimizado y por desconocimiento no lo hice.

La principal es que ando con mis cosas. No me olvido del blog, pero cada vez me cuesta más encontrar temas interesantes. Para mí era más fácil escribir cuando escribía sólo para mí. Desde que me di cuenta que había gente que lo leía pienso más en qué puede interesar a otros que en lo que me interesa a mí. Pero normalmente ando haciendo algún proyecto personal, que me parece interesante pero que no termino decidirme a contarlo por aquí.

Otro tema tangencial son los lenguajes. Para hacer los ejemplos he tenido que hacer uno en Zig, un lenguaje por completo desconocido. Es el primer código que escribo en él. Me ha llamado la atención lo complejo que puede ser su compilador. Parece un lenguaje bastante expresivo y no descarto aprender más sobre él en el futuro.

De momento estoy disfrutando bastante con el raytracer en C y Lua, es posible que lo alargue en sus capacidades.

Como lenguaje es bastante simple. Nada que no esté implementado en el ANSI C, lo encontrarás en Lua. En el libro se hace mucho hincapié en el ANSI C y en su ejecución en cualquier sistema que tenga un compilador de ANSI C que compilará la librería sin problema. Su desempeño también es alto, lleva incorporado el luajit para acelerar la ejecución y, por tanto, lo más destacable de Lua es la sencillez, la presencia en cualquier sistema y la velocidad de ejecución.

Está diseñado, al menos originalmente, para estar incrustado como lenguaje auxiliar en otras aplicaciones. Por ello, Lua es una librería de funciones escritas en C. Puede haber confusión con que cuente con su propio REPL, pero éste no deja de ser una aplicación de consola con la librería de intérprete incrustada.

A pesar de todas las ventajas hay algunas cosas que no terminan de cuadrarme por diversos motivos. La primera es que en la época de los procesadores multihilo, Lua no tenga algún mecanismo que permita la ejecución en paralelo. De hecho, en el propio PiL¹, el autor descarga en la aplicación que hospede el intérprete de Lua estos asuntos y sugiere que para la ejecución en paralelo le basta con lanzar varios intérpretes a la vez.

Otra de las cosas que me resultan un poco marcianas, y que me ha dado alguna que otra patada en el trasero mientras hacía los ejercicios, es que los índices se empiecen a numerar en 1 y no en 0 como en la mayoría, por no decir todos, los lenguajes que conozco. Quizá sea sencillo para la gente que no es programadora, pero a los que programamos en otros lenguajes, nos resulta, cuando menos, chocante.

Por otro lado, el otro día hablando con un amigo me llamó la atención sobre un punto que al que yo no le había echado mucha cuenta pero que es otra de las cosas un poco marcianas que tiene Lua: la limitación de que sólo se puede utilizar la instrucción return como la última de un bloque, por lo que en algunos casos donde se necesita un return hay que proporcionar un bloque tal que do return end.

Otro de los tropezones que me he encontrado por la diferencia entre C y Lua, es que pare éste el 0 es un valor verdadero. No siempre me ha pasado, porque viene avisado en su manual, pero cuando he estado lidiando con algún ejemplo que mezclara C y Lua, me ha ocurrido en alguna ocasión, desconcertándome un poco al principio, el que una misma expresión sea falsa en C y no en Lua. En Lua sólo tienen valor falso los valores booleanos false y nil, el resto de expresiones, como por ejemplo "" o {} o 0, son todas verdaderas.

Cabe destacar la existencia de las metatablas, un mecanismo que permite algo de magia a la hora de flexibilizar el lenguaje. Se merecen ellas solas todo un artículo por las posibilidades que ofrecen para adecuar el lenguaje a nuestras necesidades. Permiten crear nuevos tipos, hacer de Lua un lenguaje, por poner un ejemplo, orientado a objetos o lo que quieras, pues definen el comportamiento de las tablas. Además, vienen acompañadas de metamétodos, lo que nos permite ajustar esos comportamientos según los tipos que creemos con las metatablas, estableciendo operadores para nuestros tipos o métodos de acceso a los índices de las tablas.

Si alguien pregunta por mi opinión subjetiva personal, es que Lua en general es un lenguaje eficiente y sencillo, pero que mantener esa sencillez y eficiencia le lleva a tener otras cadaunadas con las que lidiar. Algo que no importa demasiado, porque todos los lenguajes tienen de eso.

Como es habitual, cuando me pongo a aprender algún lenguaje en serio, me gusta utilizarlo para algún proyecto más complejo que hacer un par de ejemplos. Para eso ya he ido haciendo la mayoría de los ejercicios que se proponen en el libro y aprendiendo esos detalles. Pero desarrollar algo desde cero es bastante más complejo.

En un ejercicio no tienes que tomar muchas decisiones, lo haces amparándote en la teoría explicada en el capítulo correspondiente y no hay un esfuerzo intelectual que requiera mucho más. El verdadero problema no es el que te ponga un libro, sino el que te encontrarás en un proyecto de desarrollo desde cero.

Sin embargo, este aprendizaje estaba dirigido a un proyecto en concreto o algo que me ronda la cabeza desde hace algún tiempo y que quería desarrollar. Pero también por el camino se me han pasado por la cabeza algunas ideas más. Al final, me ha surgido la pretensión de hacer algunas cosillas con Lua. Primero, después de quejarme de la falta de ejecución paralela, la idea loca es «pues hazlo tú mismo». La segunda una evolución de la idea original, que era hacer una aventura gráfica (isométrica) de las de point & click con Lua y Löve2D. Al final es básicamente lo mismo pero en 3D.

Lua parece un lenguaje potente y sencillo. Como todos los lenguajes tiene sus cadaunadas e incluso en el PiL habla de Luaismos, expresiones y cosas propias de Lua. Es muy rápido, pero como lenguaje para estar embebido en una aplicación sigo prefiriendo Scheme (Chibi, por poner un ejemplo) o incluso Lisp (ecl, Embeddable Common Lisp).

Con respecto a los proyectos, me atrae más el lúdico Luanti que los demás. Hacerlo sería la manera de obligarme a pensar en Lua, pues es el lenguaje embebido en dicha aplicación. Desarrollar un juego desde cero me lo plantearía si encontrara quien ayudara en algunas tareas. Supongo que texturas y modelos podrían aprovecharse de algunos módulos que los proporcionan con licencias libres, por lo que ese trabajo lo tendría al alcance y podría concentrarme en otros aspectos, como crear un mundo original, poblarlo de criaturas y PnJ con quienes interactuar e invitar a jugadores a que lo habiten.

Quizá sea más alcanzable para un programador sólo el desarrollo de una aventura completa, dentro de un juego ya creado. Aunque si contara con ayuda dicha aventura podría ser en sí misma un juego completo. Imagino una dimensión completa, con estructuras y mobs propios que pongan las cosas difíciles al jugador, que lo hagan pensar, le permitan moverse e interactuar, incluso colaborar con otros jugadores para resolverlo o conseguir un premio conjunto.

Lo primero que hay que comprender es cómo funcionan las dimensiones del gráfico. Éstas se determinan en la misma etiqueta que envuelve nuestro gráfico, la <svg>...</svg>. El eje de coordenadas comienza por la esquina superior izquierda como punto \((0,0)\). Puesto que mi intención inicial es que cada gráfico se pueda visualizar para imprimirse en un A4 apaisado, las dimensiones físicas serán de \(297mm \times 210mm\).

El código quedaría como:

<svg width="297mm" height="210mm">
  ...
</svg>

Por defecto, las dimensiones dentro de un .svg se cuentan por píxeles o px, por tanto hay que añadir mm para que las unidades se tengan en cuenta. Faltaría indicarle las dimensiones internas con viewBox. Puesto que no necesito demasiada precisión, me bastaría con dividir cada milímetro en tres puntos teóricos lo que serían \(891 \times 630\), por lo que la definición quedará así:

<svg width="297mm" height="210mm" viewBox="0 0 891 630">
  ...
</svg>

Ya, son unas medidas un tanto raras y seguramente no las más fáciles de gestionar. Pero, en general, todos los gráficos llevarán estas dimensiones. En todo caso, si hay que cambiar algo, el valor de viewBox debería mantener la relación \(ancho \times alto\) para no deformar el gráfico y que las escalas, tanto \(x\) como \(y\), sean idénticas.

Tengo una prueba de concepto algo avanzada y bastante funcional que se ejecuta sobre Emacs. Para dibujar la salida, me he encontrado con que nuestro editor favorito cuenta, de manera innata con el paquete svg.el, que permite generar código SVG desde el código elisp, sin despeinarse mucho.

La ayuda que he encontrado es un poco escasa, se circunscribe a un apartado del manual de elisp y, además, he notado que algunas cosas que SVG soporta, no están implementadas en svg.el. Pero para lo básico, que es lo que necesito, sí me sirve dicha herramienta.

Un poco de código para poner un ejemplo, generando la misma salida que el último ejemplo de SVG:

(require 'svg)
(let ((mi-svg (svg-create 200 200 :stroke-width 2)))
  (svg-rectangle mi-svg 10 10 95 95 :rx 10
                 :fill-color "#c8c9ff" :stroke-color "black")
  (svg-rectangle mi-svg 35 120 40 40
                 :stroke-color "blue" :fill-color "none" :stroke-width 1)
  (svg-rectangle mi-svg 120 120 40 40 :rx 10 :ry 5
                 :stroke-color "blue" :fill-color "none" :stroke-width 1)
  (svg-circle mi-svg 100 100 25
              :stroke-color "red" :fill-color "#ffc9ff")
  (with-temp-buffer
    (svg-print mi-svg)
    (buffer-string)))

Analicemos un poco el código:

1. La primera línea es una llamada a que vamos a necesitar el módulo svg.el para que lo vaya cargando.
2. La definición del SVG se realiza con la función svg-create que devuelve un objeto, en este caso mi-svg donde el siguiente código irá dibujando. Además podemos establecer un valor de ancho de línea por defecto. Allá donde no se especifique :stroke-width ese valor será 2.
3. Por otra parte, en el bloque de código se ha especificado el fichero donde se guardará el resultado. Una vez dibujada cada forma establecemos un buffer temporal donde guardaremos el resultado mediante la función svg-print.

Si se quiere visualizar de una manera más interactiva, podemos ir haciéndolo paso a paso en el REPL. Si lanzamos el comando ielm:

ELISP> (require 'svg)
svg

Visitar un buffer temporal.

ELISP> (find-file "buffer-temporal")
#<buffer buffer-temporal>

Al hacerlo, nos llevará directamente al nuevo buffer. Podemos dividir el marco para tenerlo a la vista mientras escribimos en ielm.

Lo siguiente que debemos hacer es crear el objeto SVG en el que dibujaremos:

ELISP> (setf mi-svg (svg-create 200 200 :stroke-width 2))
(svg
 ((width . 200) (height . 200) (version . "1.1")
  (xmlns . "http://www.w3.org/2000/svg")
  (xmlns:xlink . "http://www.w3.org/1999/xlink") (stroke-width . 2)))

Una vez que lo hemos creado, podemos asociarlo con nuestro buffer temporal:

ELISP> (svg-insert-image mi-svg)
((:image . #<marker at 1 in buffer-temporal>) (width . 200)
 (height . 200) (version . "1.1")
 (xmlns . "http://www.w3.org/2000/svg")
 (xmlns:xlink . "http://www.w3.org/1999/xlink") (stroke-width . 2))

A partir de aquí, cuando modifiquemos algo desde el ielm lo iremos visualizando directamente en nuestro buffer.

ELISP> (svg-rectangle mi-svg 10 10 95 95 :rx 10 :fill-color "#c8c9ff" :stroke-color "black")
nil

Como ilustración del modo de trabajo, se puede observar la siguiente imagen:

Para dibujos temporales, no necesitamos más, pero si lo que queremos es guardar nuestro dibujo, tenemos que conseguir la cadena SVG generada por el módulo. La forma más rápida que he encontrado es escribir el SVG en el buffer temporal mediante:

ELISP> (svg-print mi-svg)
nil

Luego iremos a dicho buffer y guardaremos el archivo con C-x C-w poniéndole el nombre que queramos.

No es una forma cómoda de dibujar y si lo que quieres conseguir son dibujos mucho más complejos, te recomiendo que utilices  Inkscape  para hacerlo, ganarás en tiempo y en salud.

Sin embargo, para generar gráficos sencillos desde Emacs, el paquete svg.el, que por otro lado ya está instalado con nuestro editor, nos sirve para realizar algunas imágenes o programar alguna salida visual para nuestros datos.

Un archivo TiddlyWiki es un archivo .html que contiene tanto los datos como el JavaScript que los visualiza. Tiene la limitación, cuando lo abres en un navegador, de no dejarte escribir el archivo de nuevo. Al darle a guardar lo que hará será descargarte una copia a tu ordenador. Si has modificado un archivo de TiddlyWiki desde el navegador y cuando vuelves a abrir el archivo ves que no se ha guardado, échale un ojo al directorio de descargas.

Por ello, si vas a hacer un uso intensivo de este sistema, es recomendable que descargues e instales TiddlyDesktop. Esta aplicación te permitirá guardar tus cambios directamente a disco. Por defecto, cuando le añades un wiki guardará copias de seguridad o versiones en el mismo directorio –o en donde tú configures–, pero también puedes evitarlo, depende de lo que te guste el riesgo.

Todo en TiddlyWiki se encuentra dentro de un tiddler y se muestra como tal. Incluyendo la configuración. Muchos tiddlers dentro de Core se refieren a parámetros y opciones de la configuración. En su organización interna funciona casi como un sistema de archivos y se organizan en directorios. Por ejemplo, los plugins se encuentran dentro de $:/plugins. Si estás trasteando con el wiki que preparé para este artículo, podrás encontrar el plugin de prueba que he hecho, como $:/plugins/notxor/basico. Y dentro de él, encontrarás algunos tiddlers ocultos como $:/plugins/notxor/basico/macros o $:/plugins/notxor/basico/estilos donde se encuentra el código del mismo.

Si estás empezando con tu proyecto de notas, te aconsejo que descargues un wiki vacío, le instales el plugin de español y comiences desde ahí. También puedes descargarte un wiki vacío ya con dicho plugin ya instalado. También un wiki que contiene la ayuda en inglés y una versión traducida parcialmente al español, por si necesitas referencia de cómo funciona.

Apenas he arañado un poco las posibilidades de tiene TiddlyWiki. Se pueden hacer cosas muy complejas. En el wiki de muestra puedes encontrar un pequeño tiddler creando un macro utilizando JavaScript para ello.

Toda la interface es configurable. Hay plugins que nos proporcionan temas para visualizar el wiki de otros modos:

Ya he hablado sobre esto en varias ocasiones y quizá por eso puede dar la impresión de que domino el tema. Algunas de las preguntas me hacen pensar que no me he explicado correctamente sobre qué es y cómo funciona el método de tomar notas y guardarlas en una caja, que es lo que significa el término alemán¹. ¿Por qué en alemán? Pues porque todo viene de un método muy personal que utilizaba el que demostró ser el sociólogo más productivo hasta la fecha: el alemán Niklas Luhmann². Este hombre, con su método, publicó 50 libros y cientos de artículos, dejando a su muerte más de 150 borradores inacabados. Lo que le hace ser considerado el autor más prolífico de la historia de la Sociología.

Una vez descubierto su método de trabajo, la propia universidad donde ejerció de catedrático ha empleado mucho tiempo en analizarlo y ha dado acceso al archivo de Luhmann³. Poco a poco, dicho método se ha ido extendiendo de boca a oreja y aparecen defensores –y también detractores– debajo de cada piedra que levantes en la Internet en sitios dedicados a productividad y herramientas. Hay gente que afirma que les funciona y otra que afirma que no. Los defensores argumentan que si no te funciona es porque quizá no lo estás empleando bien y los detractores que dicen que sí, pero que no merece la pena el esfuerzo.

Yendo al grano, los dos principios básicos del sistema son muy sencillos:

1. Principio de atomicidad: consiste en que cada nota exprese una idea.⁴
2. Principio de enlace: consiste en que las notas están relacionadas mediante enlaces entre ellas.

¿Sencillo? Sí, pero se olvidan de un aspecto aún más importante y que la gente suele pasar por alto: la dedicación y el tiempo que se deben emplear para que tu archivo sea verdaderamente útil.

Durante su carrera, Luhmann, llegó a almacenar más de 60.000 fichas de tamaño A6. En realidad, llevaba dos ficheros: uno bibliográfico con referencias y notas breves sobre el contenido bibliográfico y otro, el principal, donde guardaba las ideas y las relaciones entre las mismas. A partir del mismo fichero de Luhmann nos encontraremos que los defensores afirman que el método funciona, a Luhmann le funcionó y los detractores dicen que no especialmente, nadie ha podido generar nada nuevo a partir del archivo del autor que conserva la universidad.

¿Cómo lo hago yo? ¿Estoy utilizando el método? Pues no y sí. Es decir, el archivo llega un momento que debe alcanzar una masa crítica en la que comience a hacer su magia. Pero su magia es muy personal, porque no puedes sacar nada de donde no has metido antes. ¿Qué es lo que metes? No estás introduciendo sólo información, estás introduciendo conocimiento. Las ideas sueltas no sirven de mucho, son las relaciones entre ellas las que generan conocimiento. Por tanto, montar tu archivo es un ejercicio intelectual que posteriormente funcionará ayudándote a descargar tu mente de las tareas habituales porque ya las has hecho antes... con la ventaja adicional de que las fichas no olvidan nada.

El proceso, sobre el papel, es muy sencillo: introduces ideas y cómo se relacionan entre ellas, mediante tus fichas y los enlaces, y cuando decides escribir o repensar algún tema, tiras de las fichas de cuando ya lo habías pensaste. Si no lo has pensado con antelación, has usado el método del corta-pega o copiado directamente alguna idea que no has entendido, el método no te funcionará. Por eso, los consejos son muy sencillos:

1. Toma notas de todo, a ser posible escribiendo a mano⁵.
2. Lo importante no es guardar sólo el contenido de la idea que te ha generado, lo importante es cómo lo relacionas con el conocimiento que ya tienes. Deberías tener en cuenta si la idea corrobora o contradice a alguna otra que ya tengas, la cercanía o distancia de ambas ideas, etc. Para esto está el principio de atomicidad, cada ficha representa una idea.
3. De nada sirve una idea aislada que se puede quedar en el fondo del cajón para siempre sin volver a salir. Tienes que asegurarte de que eres capaz de alcanzar, de algún modo dicha idea cuando abras el cajón. Para sirve el principio de enlace.

Podemos distinguir también tres tipos de notas según su temporalidad o ciclo de vida:

1. Las notas temporales son recordatorios de información, en uno o dos días terminarán en la papelera.
2. Las notas permanentes son aquellas que contienen una idea que se mantendrá de manera más o menos permanente⁶ y se guardarán para siempre en el archivo.
3. Las notas de proyecto son aquellas que son relevantes durante la realización de algún tipo de tarea o proyecto y que al finalizar pueden pasar a ser permanentes o a ser descartadas.

Habría un cuarto tipo de notas, las notas de enlace⁷, que son necesarias si tu archivo está formado por tarjetas físicas guardadas en cajas. Estas notas consisten en aportar enlaces, por ejemplo, para agrupar una lista de notas dispersas por el archivador y que aglutinarían un tema, o para enlazar una nota con la que correspondería ir a continuación, pero que físicamente es imposible por razones de espacio u otras limitaciones que estén juntas. Si utilizas alguna aplicación o medio electrónico para llevar el registro, estas notas se pueden obviar.

¿Por qué le funcionaba a Luhmann y a mí no? El trabajo intelectual del amigo Niklas, estaba descargado sobre su valioso fichero. Todos los días leía, tomaba notas, las clasificaba, ordenaba y enlazaba buscando relaciones entre ellas, intentando acomodarlas en su estructura mental, cuyo reflejo era su archivo físico. Al escribirlo y guardarlo lo fijaba en la memoria y además podía dejar de gastar energía en recordarlo, porque lo conservaba, si necesitaba algún dato concreto podía volver a leer la tarjeta que escribió y así descargar su mente. Mantener algo en la memoria a corto plazo es un ejercicio bastante agotador, sólo tienes que pensar en aquellas ocasiones en que vas a comprar algo en la tienda, y te vas repitiendo la lista, es información desechable, mentalmente: confías en la repetición, no en tu memoria. Sin embargo, al escribir la nota y guardarla estás dando a esa información la suficiente relevancia como para que pase a la memoria a largo plazo y se fije en ella. En la memoria a largo plazo no se guardan datos puros aislados, para que se fijen tienen que estar relacionados con lo que ya tenemos almacenado allí, es decir, se forma y es conocimiento, no mera información. Es posible que te aprendas una lista de números para algo en concreto, pero si esa lista no se relaciona con algo, los olvidarás más temprano que tarde.

Otro de los motivos para que el archivo no termine de alcanzar la masa crítica en la que comienza a ser efectivo es la costumbre que tenemos y desarrollamos desde nuestra edad escolar a compartimentar temas. El conocimiento que hemos adquirido no está en compartimentos o almacenajes distintos en nuestra mollera, está todo mezclado y unido formando nuestro cuerpo de conocimiento. Si no se mezcla y une a nuestra mente una idea resulta mucho más difícil hacer que quede fijada en la memoria a largo plazo. Pero en la escuela nos enseñan a guardar los contenidos de matemáticas separados de los de física o lengua, como si los físicos no usaran las matemáticas para sus cosas ni utilizaran la lengua para expresarse. La separación no genera conocimiento, sólo consigue que tengamos un montón de ideas inconexas. Si no funciona en tu mente, ¿por qué debería hacerlo fuera de ella?

Otra de las preguntas que ha aparecido varias veces: ¿Qué forma tiene una nota? ¿Qué debo apuntar? Pues depende de qué herramienta estés utilizando para tu archivo personal. Especialmente si es físico, porque dependerá del tipo de tarjetas y fichero que utilices. Si es digital, dependerá de la herramienta que utilices para gestionar tu fichero. Para hacernos una idea general, vamos a pensar en una nota, como si fuera una tarjeta física. Veamos un pequeño esquema de su distribución física:

Podemos observar tres tipos de información en esa hipotética ficha de nuestro archivo:

1. Identificación: Cada ficha debe tener un identificador único. Luhmann utilizaba un sistema de numeración que mezclaba letras dígitos y signos de puntuación como la coma (,) o la barra (/) para formar cadenas estilo 22a1,1. Al hacer el archivado físico almacenaba las notas relacionadas unas junto a otras físicamente y las iba numerando, pero cuando aparecía una nota que debía ir tras la 22 y ya existía previamente una nota 23, la numeraba como 22a y la metía entre ambas, pudiendo crear así una gran ramificación de temas y subtemas. Con medios electrónicos el identificador puede ser cualquiera, siempre que sea único. Bastantes programas y sistemas recurren a establecer una cadena a partir de la fecha y hora de la creación de la nota o a utilizar UUID o una combinación de ambas.⁸
2. Nota: la parte principal de la nota está destinada a albergar la idea central de la misma. Se debe redactar con tus propias palabras y debe ser lo más breve posible, manteniendo la completa información. Como prueba de fuego: si comprendo algo puedo expresarlo de manera sencilla y completa, si no soy capaz de resumirlo, no lo he entendido lo suficientemente bien. Si necesito darle vueltas es mejor darlas en la cabeza y que la nota vaya redactada de manera que no me obligue a pensar, cuando la lea, qué quise decir, en lugar de poder leerla directamente y ya. No es raro que también puedas enlazar en el cuerpo otras notas relacionadas.
3. Referencias: El otro pilar del método Zettelkasten es la relación entre las anotaciones. En la parte inferior de nuestra ficha debemos anotar las otras notas que tienen relación con ésta, cuáles enlazan con ella. En el espacio de la nota ya podemos haber enlazado otras notas a las que ésta haga referencia, pero en este apartado deberían situarse enlaces a las notas que hacen referencia a ésta. Por supuesto, también se pondrán en este apartado las referencias bibliográficas, que sean necesarias.

¿Cómo encuentro y reúno la bibliografía? En realidad, como dije antes, Luhmann tenía dos archivos o zettekasten, uno con las notas y referencias bibliográficas, y otro el general que ya venimos conociendo.

¿Y luego qué? Pues si ya tomas nota de todo y no consigues hacerlo funcionar replanteate si estás tomándolas para recordar o para generar conocimiento. Tomar nota de todo no sirve de nada, si no hay un trabajo de elaboración posterior. De nada sirve anotar algo para no olvidarlo, si luego no lo vuelves a leer. Puedes llenar cuadernos y cuadernos, agendas y/o servilletas, con todas las ideas habidas y por haber, que para lo único que servirán es para manchar el papel. El método se centra, no en el procedimiento de guardar notas, sino en el proceso de reflexionar sobre las ideas y cómo éstas se acomodarán dentro de nuestro cuerpo de conocimiento.

Tomar notas, se convierte así, en la tarea intelectual fundamental, no sólo es escribir, es redactar con las palabras justas, pensar sobre el contenido, reflexionar sobre la idea que queremos anotar y ver cómo encaja en nuestro conocimiento. Según vayamos encajando ideas en él, es posible que éstas cambien o se maticen, respecto a su significado o respecto a las relaciones entre ellas. Por lo que deberemos modificar las anotaciones, eliminar referencias o añadirlas según nuestro conocimiento, y con él nuestro archivo, haciendo que crezca y se vaya afinando.

Puesto que estamos hablando de una técnica que lleva unos años en boca de todos –y podríamos decir que se ha puesto de moda–, han ido apareciendo varias herramientas para tomar notas dirigidas expresamente a utilizar dicho método o, cuando menos, se anuncian compatibles con el mismo.

¿Qué necesito? Pues si tienes sitio en casa y te gusta escribir a mano, necesitarás papel para las notas, bolígrafo para escribirlas y algún sistema de cajones o cajas donde guardar la fichas físicas... Pero supongo que a estas alturas la pregunta se refiere a programas, aplicaciones o sistemas informáticos en general.

Como decía antes hay un montón de programas específicos y/o compatibles con el método zettelkasten. Algunos son de pago otro son libres. Elegir es tan complicado como elegir cualquier otra cosa y además entran los gustos y ataduras personales que suelen sesgar todas nuestras decisiones sobre tecnología:

1. ¿Tiene que ser software libre o no?
2. ¿Tengo reparo a las ventanas negras con letras blancas o no?
3. ¿Lo voy a usar desde un único dispositivo o desde varios?
4. ¿Para qué sistema operativo lo necesito? ¿Pueden ser varios?
5. ¿Necesito acceso online u offline?

Según se desprende del trabajo de Luhmann, la toma de notas es una actividad más importante de lo que suponemos cuando nos enseñan a hacerlo siendo niños. Hay que prestarle una dedicación especial que pocas veces tenemos en cuenta. Lo que he visto con respecto al Zettelkasten es que hay, en general, una tendencia a quedarse en la superficie, en el proceso de la escritura y se obvia el proceso importante que es cómo se relaciona la nota que estamos escribiendo con todo nuestro conocimiento anterior. Si tenemos dificultad para situar una nota en nuestra caja, lo mismo es porque no hemos terminado de entender bien la idea o no sabemos cómo se relaciona con otras ideas que ya conocemos. En este caso, la idea puede quedar aislada e inaccesible desde otras.

Y recuerda que no necesitas pagar o comprar nada para ponerlo en marcha. Todo está a tu alcance y necesita tan sólo un poco de ingenio, no de ingeniería, personal.

Fossil-scm es una herramienta de control de versiones creada para la gestión del código de SQLite por el mismo creador de SQLite. Como sabéis SQLite nació inicialmente para proporcionar una herramienta de bases de datos a los usuarios de Tcl/Tk. De la secta, como lo llama mi colega, es el chismático más exitoso. A estas alturas es conocido por todos y una de las librerías más descargadas. Puedes encontrar SQLite en casi cualquier sitio, para usos muy diversos. Por ejemplo, un repositorio .fossil es un archivo SQLite, que se despliega desde el ejecutable fossil.

Ya he contado más veces en este blog que el repositorio lleva incorporadas algunas herramientas útiles para los equipos de trabajo: wiki, gestión de errores y muchas cosas más. Para resumirlo de algún modo sería (casi) como tener un gitea en el propio ejecutable fossil y cada repositorio se beneficiará de esas herramientas.

Una de las cosas que descubrí recientemente es que se pueden editar los archivos del repositorio desde el /GUI/Graphical User Interface. web de la aplicación. Tan sólo hay que establecer qué tipo de archivos se pueden editar.

También se podría establecer un editor externo para hacer la edición, pues aunque cuenta con una herramienta interna para hacerlo, es bastante sencilla y espartana. El repositorio, al visualizar un archivo .md lo visualizará renderizándolo y mostrándolo como si fuera una página web. Si hemos activado la edición, como veíamos antes, nos aparecerá un submenú Edit.

Al pulsar en Edit nos aparecerá el editor:

Es un editor de texto muy sencillo, aunque suficiente para escribir MarkDown, permitiéndonos previsualizar los cambios. Una vez hemos terminado con la edición, para guardar debemos hacer un commit.

La desventaja es que no es un editor potente y la ventaja principal es que se pueden hacer modificaciones desde cualquier sitio, si el repositorio es accesible con cualquier navegador web. Algo que me vendrá muy bien para escribir en aquel sitio mediante la tablet, o incluso el teléfono móvil, si, por lo que fuera, no tengo en ese momento mi portátil a mano.

Ya he hablado con anterioridad en este blog² de este lenguaje de descripción de diagramas, que junto con graphviz, es la herramienta que más estoy utilizando para realizar mis gráficos.

Sabía que dentro de fossil se encontraba un intérprete de pikchr, cada vez que se encuentra un bloque de código marcado así, visualiza el gráfico y no el código. Lo que no sabía es que además cuenta con una herramienta para escribir y modificar este tipo de gráficos.

Si seleccionamos el sandbox de pickchr nos aparecerá la siguiente herramienta:

Esta forma de hacer diagramas ya la venía empleando para realizar genogramas, algo que difícilmente se puede dibujar con graphviz:

En mi caso también, me bajé los fuentes de su página web y lo compilé para mi máquina. Al compilar simplemente crea un ejecutable que puedes copiar a cualquier parte de tu máquina donde lo pueda encontrar el sistema cuando busca el ejecutable. En mi caso, lo copié a un directorio local mío: ~/opt/bin. Desde ese mismo momento y con la ayuda del paquete pikchr-mode de Emacs puedo realizar mis diagramas desde mi editor favorito e incluirlos en bloques de código dentro de org-mode.

Cada vez me encuentro más cómodo con este lenguaje y cuando necesito hacer un script se ha convertido en mi primera opción. Sin embargo, apenas he arañado un poco la superficie haciendo un par de proyectos antes, alguno de los cuales aún no está terminado. Por lo menos, uno de ellos alcanzó su versión alfa, a la espera de que haga algunas pruebas de producción que seguramente destaparán cientos de errores.

El objetivo del proyecto que conté al principio del artículo no sólo consiste en aprender vocabulario técnico en Esperanto. También quiero aprender más cosas sobre Tcl/Tk:

• Su sistema de POO: TclOO. Hasta ahora todo lo que he hecho con este lenguaje ha tenido un enfoque más a procedimiento o incluso en cierto modo funcional. Sin embargo, quiero ver hasta qué punto me manejaré con la POO que trae incorporada.
• Expandir el lenguaje mediante un módulo C/C++. Al elegir el raytracer la intención es que la parte de cálculos intensiva se dirija a una librería que se programará en C/C++ para acelerar el render. Quiero aprender, por tanto, a programar dicha extensión. No sé si es fácil o difícil ni si lo lograré o no, pero me parece interesante.
• Aprender cómo se realizan aplicaciones multihilo. Aunque ya lo toqué por encima en uno de los proyectos, me limité a levantar un servidor que escuchaba en un puerto y además ese código lo copié de algún otro ejemplo que encontré por la red... así que no aprendí nada.

Fuera de lo que es estrictamente la secta, llevo un tiempo probando con bastante asiduidad el zen browser como navegador de trabajo. Aún no lo tengo como navegador por defecto pero no me extrañaría que en un futuro no muy lejano lo sea.

Zen es un navegador que proviene de un fork de FireFox y que tiene una serie de herramientas que mejoran la experiencia de la navegación. Por ejemplo:

En esa captura podemos ver que tengo cargado el editor de texto del repositorio fossil y puesto que estoy escribiendo en Esperanto tengo un diccionario online, cargado en lo que llaman Zen sidebar. Esto me facilita enormemente el trabajo sin estar saltando de pestaña a pestaña. Como se puede ver en los botones que hay bajo el sidebar le he puesto acceso a la wipedia, a varios diccionarios y otras páginas de consulta habituales. No sólo está el sidebar, también tiene la capacidad de distribuir distintas pestañas en la ventana de trabajo, lo que hace que sea muy fácil tener una mitad del navegador para buscar documentación mientras la otra parte la puedes utilizar para cualquier otra tarea (ahora que muchas aplicaciones corren sobre web).

Aún le faltan algunas cosas por pulir. La apariencia por defecto es muy espartana y los temas no parecen estar muy afinados. Los de FireFox no funcionan, porque la estructura de la ventana es distinta. Sin embargo, me parece mucho más acertado en cuanto a funcionalidad de lo que está FF. Más en la línea de lo que podría ser Opera o vivaldi, pero siendo un digno heredero de FireFox y no de Chrome.

Después de mis problemas de salud decidí tomarme la vida con más calma y dedicarme tiempo. La idea es no estresarme demasiado, pero mantenerme activo lo suficiente para no aburrirme, dedicándome a cosas que me gustan y/o me parecen interesantes. Me podría haber dado por el ganchillo o la papiroflexia, pero no es el caso. Así que me dedicaré a escribir más (código y otros cuentos), a leer y a traducir cosas al Esperanto.

Si alguien de los que lee esto se encuentra con ánimo, controla de Esperanto y quiere ayudar o colaborar en el proyecto puede entrar en el enlace del repositorio que puse arriba y crearse una cuenta. A partir de ese momento podrá acceder a escribir también en el foro del repositorio. A hacer comentarios y sugerencias y lo que le venga en gana. Aunque, evidentemente, el foro estará moderado por mí.

La verdad es que soy muy desorganizado cuando escribo. Algo que no es un problema cuando haces cuentos cortos, de tramas simples. Está todo controlado dentro de mi cabeza y sale más o menos del tirón, con alguna revisita para corrección. Sin embargo, en esta ocasión me he dado cuenta que debo ser algo más ordenado y llevo un tiempo rompiéndome la cabeza de cómo organizar el cotarro para no perderme en el intento.

Aunque hay quien me recomendó que utilizara alguna de esas herramientas esotéricas, no cuento con ningún software específico que me auxilie en estas tareas. Mi solución, como casi siempre la más difícil, es ponerme a retorcer otro no específico que pueda cumplir la misma tarea, pero seguramente con más trabajo. Seguro, que si me conoces estarás pensando en Emacs... y sí, lo voy a usar, pero como editor simple y llanamente, porque la herramienta que ha venido a rescatarme es Fossil.

Fossil es la herramienta de control de versiones que utilizo para muchos de mis repositorios privados. En estos he aprendido que Fossil muestra «renderizados» los archivos MarkDown (M↓) y los de Pikchr. Teniendo en cuenta que el contenido y el trabajo lo voy a leer más veces que a escribir, prefiero navegar por el repositorio viendo el «resultado» en lugar del código y además, me puedo permitir hacer tantos esquemas gráficos como necesite sin preocuparme de generar el archivo SVG.

De momento, he cogido un archivo .fossil en blanco y me he puesto a retocarlo para dejarlo más agradable de ver que he sido capaz, metiéndole algo de CSS para los renderizados, y sobre todo información y plantillas que me serán útiles cuando me ponga a trabajar. Eso gracias a que Fossil proporciona un Wiki sencillo (pero funcional) que me está siendo muy útil.

Es decir: el único commit que tiene el repositorio es el de creación. Por supuesto, no hay ningún archivo aún en él. ¿Dónde está la información? En el Wiki:

Esa información consiste en cuatro anotaciones sobre cómo escribir historias y una serie de plantillas que me serán útiles.

En realidad, el archivo .fossil no deja de ser una plantilla. El proceso será más o menos el siguiente: cuando tenga que iniciar una historia, copiaré dicho fichero desde mi directorio ~/Plantillas a mi directorio ~/Nextcloud/repos con un nuevo nombre para el proyecto.

A partir de ahí, será un repositorio que puedo clonar, pues tengo un servidor local que me hace el apaño:

cd proyectos
fossil clone http://notxor@localhost:6969/nuevo-repositorio.fossil

Esto creará una copia de nuevo-repositorio.fossil en el directorio ~/proyectos y un directorio llamado nuevo-repositorio con todo el contenido actualizado del mismo. En la URL especifico el usuario y que lo haga por http porque así directamente lo toma como el repositorio remote, siendo el repositorio local el .fossil que ha descargado. Por supuesto, en la plantilla está ya introducido el usuario notxor con una contraseña válida que me dejará autenticarme. Si hubiera algún problema, siempre queda la opción de abrir el local con

fossil ui

Luego ir al menú Admin → Users e introducir el nombre del usuario, modificar la contraseña del mismo por una de la que me acuerde y luego pegar el cambiazo de archivo en el directorio ~/Nextcloud/repos. Si por algún motivo se niega a sincronizarse con el remoto (algunas veces me ha ocurrido), borras el local y lo vuelves a clonar. Esto funciona bien, porque tengo acceso a ambos archivos, el que funciona de remote lo tengo también a mano.

Yo sigo con mi manía de emplear herramientas que no son las típicas para cosas que no son las tópicas. Cuando he hablado sobre el asunto con algún amigo, la recomendación es que utilice algo como Manuskript o alguna otra. Pero Fossil me proporciona algunas cosas que otros chismáticos no tienen a bien hacerlo, por ejemplo:

• Repositorio incluido en la herramienta. Además siendo unipersonal no habrá conflictos, ni forks ni ninguna de esas cosas raras (y será todo maravilloso y ... ¡bah!).
• Wiki para cargarlo de información de lo más variopinta que me pueda ser útil. Lo que sea interesante para varios proyectos lo pasaré también a la plantilla para que esté para las historias nuevas.
• Un foro, que será unipersonal, pero que me permitirá abrir un hilo para anotar algo y sopesar distintas posibilidades, sin embarrar el Wiki o el contenido; para anotar ideas para nuevas historias, personajes o tramas, además de para los personajes, tramas y ambientación de la historia en curso.
• Si, por algún azar encontrase alguien quiera echar una mano será tan fácil como abrirle una cuenta de «desarrollador» en el repositorio, poner el remote en algún servidor que podamos alcanzar ambos y sincronizar nuestros repositorios locales de vez en cuando.

Cuando empecé con pikchr me resultaba complicado situar elementos en el dibujo. El modo en que fluye el dibujo limitaba mi forma de trabajar. Acostumbrado a otras herramientas, donde es la propia herramienta la que elige dónde situar un elemento u otro, esperaba de ésta la misma funcionalidad. La tiene, pero ponía a prueba mi capacidad espacial a la hora de dibujar. El acostumbrarme a situar las cosas donde quiero, a guiar las líneas y los textos, a utilizar elementos invisibles para colocarlos y otros truquillos han hecho que me resulte una herramienta mucho más completa de lo que me pareció al principio. Puedes ser tan preciso como quieras, puedes dejar que fluya o forzar la posición, tú eliges.

box "Hola"; arrow; box "Mundo"

Ese código da como resultado:

  box "Hola"; arrow; box "Mundo"

Si cambiamos hacia dónde fluye:

down
box "Hola"; arrow; box "Mundo"
move
right
box "Hola"; arrow; box "Mundo"
move
up
box "Hola"; arrow; box "Mundo"

down
box "Hola"; arrow; box "Mundo"
move
right
box "Hola"; arrow; box "Mundo"
move
up
box "Hola"; arrow; box "Mundo"

Como vemos, dejar el alineamiento al propio flujo de dibujo de pikchr presenta algunos inconvenientes, que eran los que me volvía loco al principio de utilizar la herramienta.

down
box "Hola"; arrow; box "Mundo"
right
box "Hola" at 1.5cm east of 2nd box.e; arrow; box "Mundo"
up
box "Hola" at 15mm east of 4nd box.e; arrow; box "Mundo"

Podemos apreciar que se puede hacer referencia a los elementos por su orden de aparición para situar el siguiente. Vemos que en el segundo grupo de elementos se hace referencia a la segunda caja para situar la tercera a 1.5cm al este de la misma. Para acotar mejor las distancias y visualizar mejor el espacio, en el resultado he añadido acotaciones:

down
box "Hola"; arrow; box "Mundo"
right
box "Hola" at 1.5cm east of 2nd box.e; arrow; box "Mundo"
up
box "Hola" at 15mm east of 4nd box.e; arrow; box "Mundo"

# Acotamientos para visualizar mejor las medidas

X1: line thin color gray down 50% from 2mm south of 2nd box.se
X2: line same as X1 from (3nd box, X1.start)
    arrow <-> from 3/4<X1.start,X1.end> right until even with X2 "1.5cm" above thin color gray
    assert( last arrow.width == 1.5cm )

X3: line thin color gray down 50% from 2mm south of 4nd box.se
X4: line same as X3 from (5nd box, X3.start)
    arrow <-> from 3/4<X3.start,X3.end> right until even with X4 "15mm" above thin color gray
    assert( last arrow.width == 15mm )

Si habéis mirado el código para ver las acotaciones, veréis que también me aseguro que las medidas son correctas con una instrucción assert.

Cada elemento dentro del gráfico tiene una serie de propiedades. Las que más vas a utilizar son los puntos de referencia:

# Puntos de situación
B1: box rad 5mm color blue thin width 5cm height 3.5cm
    dot at B1.c color red "c" above
    dot at B1.nw "nw" above color red
    dot at B1.n "n" above color red
    dot at B1.ne "ne" above color red
    dot at B1.w "w" rjust color red
    dot at B1.e "e" ljust color red
    dot at B1.sw "sw" rjust color red
    dot at B1.s "s" below color red
    dot at B1.se "se" ljust color red

# Acotaciones de ancho, alto y radio
X1: line thin color gray down 100% from 20mm south of B1.w
X2: line same as X1 from 20mm south of B1.e
    arrow <-> dashed thin color gray from 3/4<X1.start,X1.end> right until even with X2 "width o wid" above
X3: line thin color gray left 100% from 30mm west of B1.n
X4: line same as X3 from 30mm west of B1.s
    arrow <-> dashed thin color gray from 3/4<X3.start,X3.end> down until even with X4 "height o ht" above aligned
X5: line thin color gray right 100% from 30mm east of B1.n
X6: line thin color gray right 100% from 5mm south of X5.start
    arrow <-> dashed thin color gray from X5 down until even with X6 "radius o rad" ljust

El resultado del código anteriores es:

# Puntos de situación
B1: box rad 5mm color blue thin width 5cm height 3.5cm
    dot at B1.c color red "c" above
    dot at B1.nw "nw" above color red
    dot at B1.n "n" above color red
    dot at B1.ne "ne" above color red
    dot at B1.w "w" rjust color red
    dot at B1.e "e" ljust color red
    dot at B1.sw "sw" rjust color red
    dot at B1.s "s" below color red
    dot at B1.se "se" ljust color red

# Acotaciones de ancho, alto y radio
X1: line thin color gray down 100% from 20mm south of B1.w
X2: line same as X1 from 20mm south of B1.e
    arrow <-> dashed thin color gray from 3/4<X1.start,X1.end> right until even with X2 "width o wid" above
X3: line thin color gray left 100% from 30mm west of B1.n
X4: line same as X3 from 30mm west of B1.s
    arrow <-> dashed thin color gray from 3/4<X3.start,X3.end> down until even with X4 "height o ht" above aligned
X5: line thin color gray right 100% from 30mm east of B1.n
X6: line thin color gray right 100% from 5mm south of X5.start
    arrow <-> dashed thin color gray from X5 down until even with X6 "radius o rad" ljust

Y como se puede apreciar para dibujar se utilizan comandos como right, up, down, left, es decir: derecha, abajo, arriba, izquierda. Y las cosas se sitúan south, north, east, west, es decir: al sur, al norte, al este o al oeste de un punto. También podemos situarnos en fracciones de la distancia entre dos puntos utilizando la notación:

fracción<punto1,punto2>

No hay nada como leerse la documentación y mirar todos los ejemplos que he podido encontrar. Creo que aún no he conseguido sacar toda la chicha que tiene el asunto.

En fin, pikchr me parece una herramienta bastante completa. Se asemeja a poder dibujar un SVG a partir de instrucciones simples, aunque no tiene todas las cosas que permite un SVG. Por ejemplo, no soporta gradientes o colores con canal alfa. Para la muchas de las cosas que debo dibujar me facilita la vida y si necesito esas otras cosas que no me proporciona, siempre puedo modificar el resultado desde Inkscape, por ejemplo, para añadirle fórmulas LaTeX.

Las vistas en cada perspectiva tratan de representar los objetos de una forma más o menos realista. No hace falta decir que la perspectiva más realista para nuestro ojo es la perspectiva cónica o 3D pura. Sin embargo, el problema de esta representación es que es complicado establecer una escala fácilmente dimensionable. Por eso, en la representación de sólidos más técnica se suelen utilizar aquellas otras representaciones que permiten acomodar una escala para poder medir correctamente las dimensiones del objeto. Es decir, se utilizan las proyecciones ortométricas como las cuatro que vemos arriba.

En la Figura 1 podemos observar una perspectiva oblicua, se llaman así porque presentan una vista desde un lado, manteniendo la escala fija en dos ejes. En la figura podemos observar que los ejes y y z se han colocado a 90°. Ambos mantendrán una escala proporcional a lo largo de todo el eje. El oblicuo x se representa con una escala proporcional. En este caso, se presenta a 135° con respecto a los otros dos, pero también pueden utilizarse ángulos múltiplos de 30° y 45°, dejando de lado los 90°, 180°, 270° y 360° (por razones obvias). La escala de reducción en el eje x dependerá también del ángulo seleccionado, los valores habituales son 1:2, 2:3 ó 3:4.

La ventaja de la perspectiva isométrica (Figura 2) es que al repartir el espacio en tres ángulos de manera equitativa (120º), todos los desplazamientos en cualquiera de los ejes tiene la misma escala. Este tipo de proyección es bastante utilizada en representaciones de instalaciones de fontanería, de gas, eléctricas, donde se puede representar toda la habitación a escala. Tradicionalmente ha dado nombre a la representación gráfica de algunos juegos donde se simula un mundo 3D en la pantalla.

Sin embargo, la realidad es que este tipo de juegos utilizan una perspectiva dimétrica (Figura 3). En general, esta perspectiva mantiene equivalente la escala en dos ejes, teniendo un factor de reducción para el tercero. La utilización de este tipo de perspectiva en los videojuegos es por una razón de cálculo y vistosidad. Los ángulos que se muestran en la figura pueden variar, sin embargo, manteniendo esos que aparecen en la figura, tenemos un desplazamiento en horizontal que es el doble del desplazamiento en vertical. Es decir, desplazarse en x o en y sobre la pantalla mantiene una proporción de 2:1. En pantalla, por cada pixel que se avance en vertical, se deberán avanzar dos en horizontal para un desplazamiento equivalente. Para los cálculos también es una escala adecuada: todos sabemos lo rápido que es para un ordenador (binario) multiplicar o dividir por 2.

Por último, el la Figura 4 se representa una perspectiva en la que los tres ejes mantienen proporciones distintas y por lo tanto hay que aplicarle a cada uno su factor de reducción correspondiente.

Para no perder mucho tiempo haciendo texturas para las pruebas, he hecho algunas muy básicas, aunque también podría haber descargado un paquete de texturas ya hecho, he preferido hacerlo yo todo. Para ello he utilizado como editor Krita, que cada vez que lo abro me gusta más y prácticamente me ha hecho replantearme el desinstalar Gimp.

He creado dos teselas básicas, una verde y otra ocre, para hacer las pruebas. Sobre las dimensiones básicas de 128 \(\times\) 64 he añadido 10 de alto, para dar un poco de profundidad.

Además, en los laterales he dejado a propósito un píxel de margen por cada lado, para que al dibujarlos los límites de cada tesela sean más evidentes. En muchos juegos se intenta eliminar ese efecto de rombos para mejorar la sensación de continuidad del mundo, pero en este caso prefiero mostrar las separaciones de manera didáctica.

Antes de nada comenzaremos con una representación de texturas en un mundo plano con vista cenital.

Esta es la versión muy simplificada de cómo dibujar mosaicos «isométricos» en juegos 2D. Podemos complicar un poco más las cosas y trabajar también en el eje z o para detectar el cursor:

La detección del cursor implica otro poco de cálculo. Disculpad si no me alargo con las explicaciones de esta fórmula, seguro que encontráis por internet explicaciones mejores que la mía. El código añadido para manejar el cursor es el siguiente:

-- Detectar ratón
function detecta_raton()
   -- obtener las coordenadas del cursor
   local xr = love.mouse.getX()
   local yr = love.mouse.getY()
   -- convertir las coordenadas de pantalla a tesela
   local xt = math.floor((yr / Ht) + (xr / Wt)) - 2
   local yt = math.floor((yr / Ht) - (xr / Wt)) + 2
   -- dibujar la textura de tesela seleccionada
   dibuja_tesela(tesela_cursor, xt, yt)
end

Después en la función love.draw() se añade una llamada a esta función al final, tras haber dibujado el mosaico.

Lo único que puedo aconsejaros es que juguéis un poco, si queréis profundizar. Instalar Löve2D y retorcer el código fuente junto con las imágenes utilizadas, que podéis encontrar en este archivo. Quizá incluso decidiros a hacer un pequeño proyecto a partir de esa base. O si preferís otro lenguaje u os da pereza el instalar Lua y Löve, el código es tan sencillo que seguro podéis adaptarlo a cualquier otra herramienta o lenguaje.

Descargar fuentes pinchando aquí → perspectivas.zip

La respuesta a esta pregunta tiene varias vertientes. Por un lado, está el hecho de la elección del lenguaje. Por otro, también podemos preguntarnos por la necesidad de una nueva herramienta de creación de aventuras de texto. Por último, también nos podemos preguntar por qué hacer «aventuras de texto» y no otro tipo de juegos.

El motivo para elegir las aventuras de texto, también llamadas ficción interactiva o aventuras conversacionales, obedece a varias causas. Es necesario recordar, que la creación de esta herramienta, aunque puede ser utilizada de manera genérica, está enfocada a proporcionar actividades lúdico-formativas en planes de prevención del acoso escolar. Las aventuras de texto nos proporcionan las siguientes ventajas en ese ámbito:

• Fomenta la inclusión: Podemos encontrar personas con algún tipo de déficit visual o auditivo que tienen problemas a la hora de realizar actividades lúdicas, como un videojuego convencional. Sin embargo, un juego basado en texto puede integrarlas, simplemente utilizando las herramientas de accesibilidad que cualquier sistema operativo trae ya incluidas.
• Fomenta la comprensión lectora: Toda la aventura se basa en interacciones de texto, los participantes deben leer y comprender qué está sucediendo para responder adecuadamente a las acciones de los otros jugadores y a los eventos acaecidos en el mundo virtual que se presenta.
• Fomenta la imaginación: Una aventura conversacional, si está bien diseñada, produce una inmersión completa en un mundo virtual que estando basado en descripciones de texto, es un completo ejercicio de imaginación para los jugadores.
• Crear simulaciones: La ficción interactiva genera entornos virtuales que pueden ser utilizados para simular situaciones peligrosas de la vida real sin exponer a los jugadores al peligro.

Existen en la actualidad un montón de herramientas para la creación de este tipo de aventuras y quizá se podría haber utilizado otra cualquiera con los mismos objetivos. Sin embargo, se nos presentarían problemas de difícil solución:

• Ficción interactiva: La mayor parte de las herramientas de ficción interactiva están enfocadas al juego individual. Algunas, como AGE¹, sí tienen en cuenta el modo multijugador, pero se encuentra abandonada desde hace años y no se puede asegurar que su funcionamiento sea correcto.
• MUD: Un MUD², es un tipo de juego de texto, precursor de los actuales MMORPG³. La utilización de este tipo de juegos como herramienta es compleja, ya que están pensados para la creación de un mundo virtual estable que debe ser mantenida y desarrollada en el tiempo.

En ese sentido Trokola proporciona un sistema que se equilibra entre ambos aspectos. No necesita un mundo virtual infinito, sino tan sólo lo mínimo para poder crear una aventura específica.

Por último, para la elección del lenguaje de programación se han tenido en cuenta algunos otros aspectos:

• Sencillez: Se buscaba un lenguaje sencillo que pudiera ser utilizado por cualquier persona, incluso los no programadores. La máxima de Tcl/Tk es «todo es texto». Cualquier expresión se trata como texto. Tanto el código como los datos son texto puro, lo que los hace también intercambiables.

  Otra de las características del lenguaje es la homoiconicidad es decir, toda la sintaxis del mismo presenta una estructura idéntica, en el formato:

  comando arg1 arg2 ... argN
  

• Multiparadigma: Es un lenguaje que puede ser utilizado de diversas maneras, tanto desde un enfoque funcional, como desde un enfoque de lenguaje orientado a objetos o procedural.
• Gráfica: El lenguaje Tcl, proporciona a su vez un conjunto de instrucciones gráficas mediante Tk, (el Tool Kit de Tcl⁴) que permite la creación de GUIs⁵. Un posible proyecto futuro sería alejar a los usuarios de la temida consola de comandos y de otros detalles como las conexiones a través de la red. O proporcionar una herramienta gráfica que permita crear un mundo básico rellenando algunos formularios en una ventana.
• Multiplataforma: El lenguaje y sus librerías se pueden instalar en cualquier sistema operativo: GNU/Linux, Windows®, MacOS® o, incluso, Android® a través de Termux. En el primero es bastante habitual encontrárselo ya instalado, y el los demás es muy sencillo de instalar.

Toda la herramienta se ha programado sin recurrir a dependencias de librerías externas, de tal manera que teniendo instalado el lenguaje y teniendo el código fuente de Trokola, no se necesita instalar más.

Trokola proporciona dos elementos principales. Por un lado, tenemos el servidor y por otro la simulación de mundo.

• El servidor: Este es un programa centralizado en la red que proporciona interacción a través de comandos de los usuarios. Por tanto, su función principal es responder a las peticiones de los usuarios conectados según el modelo de mundo cargado.

• El mundo: Es una abstracción generada por código, de hecho toda la información está contenida en un diccionario, que es un tipo de conjunto de datos que se expresa mediante pares clave-valor. El modelo de mundo que proporciona Trokola es muy básico. Permite separar el mundo en localidades, es decir, son entidades que representan porciones de espacio que pueden contener otras entidades en su interior. Las interacciones básicas con las localidades es la posibilidad de desplazar a los personajes por ellas, creando la sensación de movimiento.

  Otro de los elementos básicos que proporciona el modelo básico de mundo virtual es la representación de objetos, que son entidades con diversas características. El subtipo más destacable son los contenedores, que son entidades que pueden tener otras entidades subordinadas.

  Por último, estarían los personajes. Aunque se pueden crear personajes por código, en Trokola se espera que los personajes estén jugados por personas reales. De estos personajes podemos distinguir dos tipos fundamentales: los jugadores base y los administradores. La diferencia entre ambos, es la posibilidad que tienen los administradores de interactuar con el servidor y no sólo con el mundo.

  La creación de un juego consiste en sobrescribir las características del mundo virtual básico creando comportamientos nuevos o modificando los ya existentes.

Es complejo decidir qué acciones o características incluir en el mundo básico. Un mundo básico, más básico, permite una mayor flexibilidad a la hora de programar las aventuras, pero también implicará que necesitarás picar más código para hacerlas.

1. Creación de una aventura básica para probar el sistema. Consistirá en una aventura multijugador para 3 ó 4 jugadores que sirva para probar a fondo todas las características del sistema. Además, se utilizará como ejemplo de programación en la documentación que estoy escribiendo sobre cómo crear aventuras con Trokola.
2. Escribir la documentación de la herramienta. Consistirá en dos documentos fundamentales: primero el manual de usuario enfocado a la programación de aventuras sencillas a partir del mundo básico implementado y a cómo explicar el mecanismo de juego a posibles participantes; segundo un manual del programador que explique cómo funciona la herramienta y permita a los más avanzados crear sus propios mundos básicos o modificar el existente para completarlo o hacer que se comporte de una manera diferente.
3. Facilitar el acceso. Siendo un servidor remoto, me planteo crear una herramienta, bien web o bien mediante Tk para conectarse a un juego. De manera que se pueda realizar la actividad lúdica sin recurrir a intimidantes⁶ consolas de texto.

Aún queda mucho trabajo por hacer y este proyecto se lleva muchas horas de trabajo, pero está resultando gratificante. Ahora mismo toca ir implementando una aventura sencilla y buscar probadores que quieran jugarla conmigo para ayudarme a depurar errores, corregir sorderas⁷ del mundo básico, aumentar la cantidad y calidad de los mensajes de respuesta y, en fin, un montón de tareas que aún faltan o son manifiestamente mejorables.

Otro proyecto futuro, que no depende sólo de mí aunque resulta imprescindible desde mi punto de vista para esta herramienta, es su utilización en educación/prevención en el ámbito escolar como comenté más arriba. Me gustaría poder estudiar si esos efectos de su utilización, que espero, son ciertos o no. Por tanto, en el futuro me propongo hacer algunos estudios objetivos sobre su funcionalidad y cómo podemos ajustar su uso para maximizar la efectividad del cambio que queremos provocar en adquisición de conocimientos, hábitos saludables o conducta ajustada.

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.

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)

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.

Llevo un tiempo, algunos años, editando libros digitales en Esperanto. Me gusta poder leer en formato epub en mi tablet o en mi lector de libros electrónicos, pero la oferta que hay es poca. La mayoría los encuentras en pdf y los pocos que encuentras en epub no están demasiado cuidados, contienen múltiples errores, e incluso, muchas veces, el archivo no cumple con los estándares epub.

Lo último que estoy intentando editar es una obra de Antonio Marco Botella sobre el movimiento esperantista en España. Un completo resumen histórico de unas 800 páginas que la Hispana Esperanta Federacio escaneó. También han trasladado mediante OCR esos contenidos a un archivo .doc, monolítico y plagado de errores que no ayuda a su edición. De hecho pedí que me pasaran los archivos escaneados originales para hacer yo la conversión a algo más legible. Las imágenes además son de una calidad pésima. Algunas se han podido arreglar un poco con mucha paciencia, pero la mayoría son intratables, pues parecen un escaneo de una fotocopia. En fin, si consigo toda la información tardaré unas dos semanas en tener un libro epub decente.

Mientras espero, le doy a otros proyectos.

Creo que ya hablé por aquí de este proyecto y debo añadir que voy avanzando poco a poco. Para ir cumpliendo tareas, me planteé el utilizar el clásico juego básico de Vampiro¹. En este momento están implementadas todas las acciones necesarias para completar el juego, excepto la corrección de un bug persistente en la interacción con objetos contenedores cerrados con llave o que necesiten un objeto para ser abiertos. Una vez arreglado ese bug el juego se podrá completar.

Posteriormente, la idea es consolidar lo que ya está hecho sobre interacción entre jugadores y la creación de una aventura sencilla para varios jugadores. Mis primeras ideas son crear una especie de scape room para tres o cuatro jugadores. Por ejemplo, estar en una nave dañada por choque contra un asteroide que inicia la cuenta atrás para autodestrucción y los pocos supervivientes tienen que alcanzar la cápsula de salvamento. También lo había pensado con un barco hundiéndose después de un ataque pirata o un pueblo en las faldas de un volcán que entra en erupción y la lava se acerca al mismo. En todos los casos, los puzles pueden ser muy similares, aunque la historia de fondo sea algo distinta.

El proyecto va avanzando, aunque entre temas de trabajo y otros proyectos se está quedando un poco rezagado. Me falta muy poco para tener una base ya funcional —aunque supongo que plagada de errores y bugs que corregir— para iniciar las pruebas. Espero encontrar probadores para el juego conjunto y que podamos coordinar una sesión de tres o cuatro jugadores simultáneos. No debería haber mucho problema en montar un servidor en alguno de los vps que hemos contratado.

Todo está programado en Tcl, e incluso los juegos que se creen irán en este lenguaje. Estoy intentando que sea un sistema flexible, con bastantes opciones de configuración para ajustar el comportamiento del servidor a los gustos y/o necesidades del creador de la aventura... y eso también está siendo una fuente de sorpresas que es necesario desenmarañar cuando estoy intentando depurar un bug o un error.

De momento, está todo en un repositorio fossil privado. En el futuro, cuando ya esté la cosa más avanzada, seguramente haré público el repositorio autoalojándolo en el mismo sitio del servidor para que se pueda descargar el código o informar de bugs o acceder al manual de funcionamiento y creación de aventuras. Además de proporcionar mecanismos para alojar aventuras de otros posibles creadores o usuarios de la herramienta que quieran utilizarla. Aunque en principio se pensó para montar pequeños servidores en redes locales, creo que sería bueno que se pudieran jugar a través de Internet.

Es otro proyecto en el que ando metido con deesix. Uno de los asuntos que más gustan en el ámbito motorista es salir de vez en cuando a cazar unos huevos fritos con algo. La mayor parte del tiempo cada uno va en su moto con sus pensamientos y la interacción suele ser por gestos, más o menos establecidos ya por la costumbre.

De un tiempo a esta parte, es muy habitual ver a bastantes motoristas que llevan caros intercomunicadores para poder hablar unos con otros. El más popular es el varato v6, del que yo mismo tengo un par. Sin embargo, esas comunicaciones son limitadas por número de intercomunicadores que se pueden sincronizar (máximo de 6), hay que apretar el botón asignado a cada motorista con el que quieres hablar (lo que no siempre es posible y suele ser complicado con los guantes puestos) y a menudo se pierde la comunicación por las limitaciones de distancia del bluetooth.

Mi idea es proporcionar una aplicación para el teléfono que cree un chat vozIP que permita grupos más grandes y sin limitación de distancia. Además, bastaría para conectarse un manos-libres de los que hay para moto, que son más baratos que los intercom. Ya estamos haciendo algunas pruebas con mi intercom cuando salgo en moto, aunque aún no hemos podido escalarlo a grupos. La desventaja será que gasta datos de la cuenta del móvil.

Otra de las funcionalidades pensada es la geolocalización de los miembros de los grupos. Algo que puede ocurrir —de hecho ocurre muchas veces cuando el grupo es heterogéneo—, es que los más rápidos pierdan a los más lentos, o que algún miembro se quede descolgado por algún problema en la moto o en el motorista. La idea es proporcionar una manera de buscar dónde está el grupo, para que el miembro descolgado los alcance, o que el grupo vaya a apoyar a quien se ha tenido que detener por una avería o lo que sea que le impida continuar. Para ello se contempla también que se puedan cargar trazas de la ruta desde otras aplicaciones para que todo el mundo conozca el plan.

Todo esto, de momento, está en mantillas y esta reseña es el vaporware habitual. Aunque nuestra intención es ponerla en la tienda y sacar algo de dinero, si es posible.

En la Asociación PICA, de la que soy socio de número y para la que colaboro en un montón de frentes, se ha planteado la necesidad de unificar algunas cosas. Como asociación ha ido creciendo en varios ámbitos geográficos, pero eso lo que hace es que aparezca la necesidad de unificar criterios de formación de los miembros, de gestión de eventos, de comunicación entre miembros del mismo capítulo e inter-capítulos, por ejemplo para coordinar cursos, charlas informativas, charlas formativas, etc.

En la próxima asamblea nacional, donde nos reuniremos un fin de semana para tratar todos esos temas, la Sra. Vicepresidenta de PICA Aragón, presentará la propuesta de montar estas herramientas, especialmente un nodo de Mastodon, gestionado por nosotros, que podamos ofertar como una red social segura para los menores. Si la propuesta es aceptada, se contratará un vps, al que se mudará el dominio actual y en el que se montarán bastantes más servicios de los que ahora tenemos.

De momento, estoy en la redacción de la propuesta y la presentación para su aprobación en asamblea.

De vez en cuando encuentro temas interesantes que se podrían tratar en el blog, pero no termino de ponerme a hacerlo. Todo lo que llevo investigado últimamente sobre estadística y Análisis Big Data estaría bien recogerlo. Algunas veces con R, pero también con otras herramientas... incluso con Tcl/Tk, al que últimamente le estoy dando más en serio.

Otra de las cosas que me estoy planteando, después de tener contratado tres vps es mudar este blog a un dominio propio, abandonando el subdominio donde se encuentra en la actualidad. Supongo que romperá algunos enlaces, aunque mi idea inicial sería que el subdominio actual redirija al dominio que cree. Aún no tengo decidido nada, pero es posible que en un futuro ocurra, si consigo encontrar tiempo para hacerlo.

1. No me da la vida...
2. No me da la vida...
3. Uff, no me da la vida...

El código utilizado para las pruebas con algunas modificaciones opcionales, que luego contaré, es el siguiente:

(use-package howm
  :ensure t
  :config
  (setq howm-home-directory "~/howm/")
  (setq howm-directory "~/howm/")
  (setq howm-keyword-file (expand-file-name ".howm-keys" howm-home-directory))
  (setq howm-history-file (expand-file-name ".howm-history" howm-home-directory))
  (setq howm-file-name-format "%Y/%m/%Y-%m-%d-%H%M%S.txt"))

Todo muy sencillo de entender: se pide el paquete howm y se establece un directorio de trabajo, en mi caso ~/howm/. También un archivo con las claves o etiquetas y otro archivo con el histórico. Ambos archivos ocultos en el directorio de trabajo, para que howm los ignore en las búsquedas y los utilice sólo cando pides las claves o el histórico. La última línea es el formato del nombre del fichero cuando se crea una nota. Si te fijas, las quiero organizadas por años y meses. Es decir, cuando creo una nota lo hará en el directorio de su año %Y/ y de su mes %m/, luego el nombre de la nota será el habitual de howm. Además le doy la extensión .txt. Las creo en .txt por defecto, porque en org-mode la tecla C-c , está habilitada para asignar la prioridad a un encabezado y choca, en este caso, con howm. Para compensar, estoy intentando adquirir el hábito de tener una perspectiva de notas abierta, con el menú principal de howm abierto.

Siguiendo con la configuración, otra función que puede ser interesante es la de nombrar los buffers al abrirlos con el título del mismo, en lugar del nombre del archivo, que suele ser el numérico de la fecha, como acabamos de ver. Para ello, se puede añadir en la configuración:

(add-hook 'howm-mode-hook 'howm-mode-set-buffer-name)
(add-hook 'after-save-hook 'howm-mode-set-buffer-name)

Por mi parte, de momento mantengo los nombres numéricos. Algunas veces, cuando hay varios apartados o encabezados en la nota, en lugar de poner el primer título, me pone el segundo o el tercero y eso me desconcierta más que la fecha de creación.

También se puede buscar información en otros directorios, no sólo el de howm que hemos visto arriba. Ahora mismo yo lo tengo configurado para que busque también en el directorio donde tengo las notas de denote y en toda la base de datos de artículos de este blog.

(setq howm-search-path '("~/Notas" "~/blog/articulos"))
(setq howm-search-other-dir t)

Las búsquedas tardan unos segundos por las miles de entradas que debe manejar, sin embargo, la capacidad de centralizar toda la información relevante de mi máquina hace que valga la pena esperar un momento.

Primero un listado de teclas y funciones, para después meternos con otras explicaciones sobre cómo usarlo.

No están todas las funciones. Por ejemplo, me he saltado las de navegación entre notas como howm-last-memo o howm-next-memo. Veremos mejor cómo crear notas y cómo listarlas. El sistema es bastante visual y si, al final, necesitas las teclas de movimiento, terminas aprendiéndotelas. Otra función que me está gustando mucho y que no tiene tecla asignada es howm-simulate-todo, que permite navegar la vista de tareas por hacer posicionándote en otros días distintos a la fecha actual.

En la imagen se muestra el menú principal (C-c , , o M-x howm-menu) nada más instalar la herramienta. Al abrir este menú por primera vez, howm crea un archivo en el directorio de trabajo que se llama 0000-00-00-000000.txt. Éste contiene el menú principal, aunque podemos configurar otro a nuestro gusto o modificar éste para adaptarlo a nosotros. En el mismo archivo se encuentran instrucciones de cómo hacerlo.

Si te despista tanta cosa por el buffer aquí va una pequeña descripción de lo que significa cada parte:

• La primera línea es el título de menú. Lo vemos marcado con la sucesión <<< que indica que es una etiqueta.
• Botonera: Inmediatamente debajo hay una serie de botones (el texto marcado como [xxx]) con su tecla rápida justo al lado.²
• Agenda: Muestra una lista de las cosas que se encuentren marcadas como pendientes (To do) o como tareas de la agenda (Schedule).
• Recientes: Una lista de las notas recientes.
• Aleatorias: Una lista aleatoria de notas... puede que nos muestre alguna nota que tomamos sin haberla enlazado y que no hemos vuelto a abrir.³
• Leyenda o ayuda: El bloque inferior muestra instrucciones del formato de las fechas en las notas, para que se muestren en el bloque de agenda y una manera de cómo recordar más fácilmente dicho formato.

Si quieres utilizar este ingenioso método de agenda, te sugiero que pienses en las fechas como «peces» que nadan en las ominosas aguas del olvido. Algunas veces, se dejan ver en la superficie y otras se hunden. Según sea su prioridad, cuanto más alta la prioridad más arriba nadará nuestro pez... digo mostrará el recordatorio.

El sistema hace distinción entre «notas» y «recordatorios». Las notas se espera que sean más extensas, tengan un título y un contenido. Se pueden crear mediante la combinación de teclas C-c , c o pulsando la c en el buffer del menú que vimos antes.

El cursor nos aparece en la primera línea que comienza con un signo =. Toda línea que comience con ese signo se considerará una cabecera y es posible crear notas con varias de esas líneas para que se muestren de manera independiente... pero estoy adelantando acontecimientos.

La estructura de la nota se puede modificar en la configuración estableciendo otra plantilla, pero de momento, para las pruebas no he modificado nada. El día de la fecha actual aparece remarcado en color naranja y a continuación hay un enlace (remarcado en azul) a la nota desde la que se creó esta, en el ejemplo la hemos creado desde el menú y por tanto enlaza esta.

En el título he escrito un lacónico «Primera nota», puesto que es un ejemplo y he añadido una frase bajo. La nota ya debería aparecer en el apartado de recientes del menú⁵.

Aún no he terminado de probarlo, he hecho una importación de notas desde denote a este sistema, en otro directorio y adaptando el formato.

De momento, no me aclaro con la agenda... mi cerebro no procesa bien el sistema de prioridades que utiliza el chismático. Aún así, ofrece una vista completa y permite verlo todo en un simple buffer, acceder a la nota donde está el asunto anotado y hacer las modificaciones de manera rápida y sencilla.

Otra cosa que debo vigilar es mi tendencia a dejarme todos los buffers abiertos. En howm, sin casi darme cuenta, puedo tener cientos de ellos abiertos por mi despiste. Supongo que cuando me acostumbre a que se visualiza todo sin necesidad de pulsar RET, el número de buffers disminuirá significativamente. De momento, he cogido la costumbre de abrir una perspectiva con el nombre de notas y el menú de howm preparado para las consultas, aunque aún tengo muy automatizado el acceso a las notas de denote. De momento, mantengo las dos herramientas y ya decidiré en el futuro cuando tenga más claro con cuál me es más fácil trabajar.

Pues ahí os lo dejo para que lo trasteéis.

En el momento de escribir este artículo aún estoy de pruebas. La idea es sustituir los paquetes de iconos, por sus equivalentes:

• all-the-icons por nerd-icons
• all-the-icons-dired por nerd-icons-dired
• all-the-icons-ivy y all-the-icons-ivy-rich por nerd-icons-ivy-rich
• all-the-icons-ibuffer por nerd-icons-ibuffer

Es decir, los paquetes se corresponden unos a otros según los utilices. Si en lugar de utilizar dired-sidebar para ver los directorios, utilizar treemacs tendrás que configurar treemacs-nerd-icons en lugar de treemacs-all-the-icons.

Puesto que en mi caso sólo utilizo los paquetes citados en la lista anterior he escrito la siguiente configuración siguiendo las instrucciones de sus repositorios:

• Configuración del paquete principal nerd-icons:

  (use-package nerd-icons
    :ensure t)
  

• Configuración de iconos para ivy:

  (use-package nerd-icons-ivy-rich
    :ensure t
    :init
    (nerd-icons-ivy-rich-mode 1)
    (ivy-rich-mode 1))
  
  ;; Visualizar iconos
  (setq nerd-icons-ivy-rich-icon t)
  
  ;; Visualiza los iconos en color
  ;; respetando `nerd-icons-color-icons'.
  (setq nerd-icons-ivy-rich-color-icon t)
  
  ;; Tamaño del icono
  (setq nerd-icons-ivy-rich-icon-size 1.0)
  
  ;; Soporte para project
  (setq nerd-icons-ivy-rich-project t)
  
  ;; Definitions for ivy-rich transformers.
  ;; See `ivy-rich-display-transformers-list' for details."
  nerd-icons-ivy-rich-display-transformers-list
  

• Configuración para dired (lo que incluye también dired-sidebar como hemos visto en las imágenes del principio del artículo):

  (use-package nerd-icons-dired
    :hook
    (dired-mode . nerd-icons-dired-mode))
  

• Configuración para ibuffer:

  (use-package nerd-icons-ibuffer
    :ensure t
    :hook (ibuffer-mode . nerd-icons-ibuffer-mode))
  

Al igual que ocurría con los iconos de all-the-icons, necesitas tener instaladas las fuentes para poder visualizarlos. En este caso se utilizan los iconos que proporcionan las fuentes de Nerd fonts. En esa misma página encontrarás fuentes que puedes descargarte para usarlas, por ejemplo, para configurar tu terminal. Esto lo hice, y lo recomiendo, para mejorar la experiencia en modo texto. Para instalar las fuentes necesarias para el modo GUI, la forma más cómoda es utilizar el comando nerd-icons-install-fonts. Si quieres utilizar otra fuente que no sea la que instala por defecto, deberías configurar el paquete de la siguiente manera:

(use-package nerd-icons
  (nerd-icons-font-family "Fuente Nerd Icons Mono que te guste"))

Es posible, si utilizas dired-git para visualizar información de los repositorios git en el modo dired que tengas algún problema. Esto es porque dired-git depende de all-the-icons y es posible que al entrar en dired a un repositorio se peguen un poco all-the-icons-dired y nerd-icons-dired. Si no dependes mucho de esa información y te gustan más los iconos de nerd-icons pues desinstala dired-git. Si por el contrario dependes de la información que te proporciona dired-git pues no instales nerd-icons-dired. Es una decisión totalmente personal.

Como siempre, en Emacs no hay una sola manera de hacer las cosas: siempre encuentras paquetes que hacen cosas parecidas y que te permiten las mismas funciones desde otro punto de vista, desde otra forma de hacer las cosas.

De momento seguiré probando nerd-icons, aunque seguramente termina cambiando algo de su configuración. Me despistan los colores y lo mismo encuentro alguna manera de que sea más amable para mis ojos.

Siempre lo he visto escrito con la «T» mayúscula y también sé, que como ocurre con TeX, la letra «x» no es una equis, sino una «χ» griega. Pero como los sonidos guturales «g» o «j» se les atraviesa a los guiris en la garganta, suelen preferir pronunciar el nombre tal que TeKinfo.

El sistema Texinfo, en la actualidad, es independiente de Emacs, aunque nació para hacer la documentación de nuestro editor favorito. Comenzó como el sistema de ayuda de hipertexto que incluyó Stallman en el año 1975–1976 para documentar Emacs y que sirviera de ayuda al usuario. Después, en los primeros años de la década de los 90 del siglo pasado, se tradujo al sistema a lenguaje C, en dos comandos: el makeinfo, que generaba la documentación y el info, que permitía navegar el contenido sin necesitar un buffer de Emacs.

En 2012, se sustituyó makeinfo por una versión en Perl llamada texi2any, que derivó de una implementación anterior llamada texi2html, que generaba la documentación en HTML para poder leerla en cualquier navegador y no depender de info ni de Emacs.

En la actualidad, los formatos que se pueden generar son los siguientes:

• Info: el formato de hipertexto original.
• Texto plano.
• HTML: En dos formatos. El primero es una sola página con enlaces internos, pero también podemos generarlo con una página para cada nodo de documentación.
• epub 3: Es un formato diseñado para documentos que deben leerse en dispositivos electrónicos.
• DVI: Este formato es el de salida por defecto de TeX. Es un formato binario destinado a imprimir en papel, aunque también puede visualizarse en pantalla.
• PostScript: es un lenguaje de descripción de página, muy popular hace unos años gracias a las impresoras postscript que realizaban la impresión mediante dicho lenguaje. También se puede visualizar en pantalla.
• PDF: junto con dvi y postscript completa el trío de documentos para impresión. Este es un formato popularizado por Adobe® Systems.
• LaTeX: es un lenguaje de descripción de documentos. Puede utilizarse como paso intermedio para modificar luego el aspecto de la documentación generada.
• DocBook: se genera un archivo XML compatible con el sistema DocBook, que sirve para crear manuales en varios formatos.
• XML: al contrario que en el formato anterior, se generan unos archivos .xml que no se pueden visualizar con navegadores o para generar otro tipo de formato de documento. Se utiliza un texinfo.dtd incluido en la distribución de Texinfo para utilizar otras herramientas de lectura de XML para acceder a ellos.

Si has utilizado con anterioridad TeX o LaTeX sabrás que cuando quieres introducir alguna instrucción o comando utilizas el carácter especial «\». En Texinfo el carácter que marca un comando es @.

Pongo un ejemplo simple para que se vea el formato y ahora lo comento todo un poco más despacio. El documento que he preparado para la prueba se llama ejemplo.texi (lo podéis descargar para trastearlo) y el archivo generado es ejemplo.info (también lo podéis descargar).

\input texinfo
@setfilename ejemplo.info
@documentencoding UTF-8
@documentlanguage es_ES

@set version 1.0
@set actualizado 9 de marzo de 2024

@settitle Mi fantabuloso manual @value{version}

@copying
Esto es un ejemplo cortito de un archivo Texinfo.

Copyright @copyright{} 2024 Free Software Foundation, Inc.
@end copying

@titlepage
@title El título de la documentación

@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage

@contents
@node Top
@top Ejemplo
Este es el manual que quiero escribir
(versión @value{version}, @value{actualizado}).

@menu
* Primer capítulo::           Primer capítulo del manual.
* Segundo capítulo::          Otro capítulo para rellenar.
@end menu

@node Primer capítulo
@chapter Primer capítulo

Ahora mismo no tengo muy claro qué debería escribir para hacer el ejemplo

Un bloque con una lista numerada:

@enumerate
@item
El primer ítem de la lista.

@item
El segundo ítem de la lista
@end enumerate

@node Primera sección
@section Primera sección

Primera sección del primer capitulo.

Enlaces a otro nodo:

@itemize
@item
@@ref@{Segunda sección@} @result{} @ref{Segunda sección}

@item
@@xref@{Segunda sección@} @result{} @xref{Segunda sección}

@item
@@pxref@{Segunda sección@} @result{} @pxref{Segunda sección}
@end itemize

@node Segunda sección
@section Segunda sección

La segunda sección del primer capítulo.

@node Segundo capítulo
@chapter Segundo capítulo

Esto es el segundo capítulo... es corto ¿no?

@bye

Visionando el archivo generado a través de la ayuda de Emacs, la apariencia sería así:

No quiero enrollarme mucho: Es una herramienta interesante y merece la pena echarle un ojo si necesitas escribir documentación, porque se creó para eso: Texinfo es, realmente, un sistema potente de documentación. El compilador texi2any y el visualizador info son fáciles de instalar, si no los tienes ya instalados en tu máquina. Ocupan poco espacio y pueden ser verdaderamente útiles.

Por ejemplo, uno de los libros que suelo recomendar para aprender a programar en LISP es Structure and Interpretation of Computer Programs, cuyo repositorio (no oficial) podéis encontrar en https://media.githubusercontent.com/media/sarabander/sicp-pdf y veréis que utiliza una mezcla de Texinfo y LaTeX, que da como resultado un pdf bastante agradable a la vista. El sicp.texi necesita una limpieza antes de generar el info si lo quieres consultar desde Emacs (que poder, se puede).

Como propósito personal, voy a documentar el proyecto en el que ando programando a ratos con esta herramienta, en lugar de LaTeX, que suele ser mi elección más habitual. Si no me encuentro cómodo, no me costará nada generar el LaTeX con lo que haya escrito hasta entonces y continuar a partir de ahí.

Como algunos que pasan por este blog ya sabréis, colaboro con una Asociación sin ánimo de lucro que trabaja con menores que sufren cualquier tipo de abuso. Lo que más nos piden es atención para víctimas del acoso escolar. Por eso, vamos por los centros educativos dando charlas de prevención... No me interpretéis mal, las charlas están bien: hablamos de muchas cosas relacionadas e informamos a los chavales de esos hechos que pasan «desapercibidos» en el acoso escolar, como que cualquiera de nosotros puede ser un abusador o una víctima. O, de manera más habitual, un consentidor si lo ven y no se lo dicen a algún adulto.

Quiero elaborar algo más formal y estandarizado que ir un par de mañanas a soltar una charlita. En su día ya hicimos un plan más ambicioso para fomentar la educación emocional en los Centros Educativos. Pero quedó en el cajón de posibles. Así que mi batalla continúa.

Después de analizar muchos planes (formales) de prevención del acoso escolar me he encontrado con un montón de ellos que utilizan cuentos o cómics para introducir los temas a tratar en las sesiones de prevención dirigidas por el tutor o personal especializado. Todos estos planes hablan de las características que hacen del cuento una herramienta muy interesante para estas actividades. Destacan, entre otras:

• El valor propedéutico³ de la narrativa.
• El valor intrínseco de los cuentos para:
  • Fomentar la imaginación
  • Expresar sentimientos y emociones
  • Educar valores

Hay muchas más, pero las más comunes sobre las que he encontrado referencia a distintos estudios son los que afirman esto. Lamentablemente, en muchas de las referencias no he podido seguir el enlace a los estudios en sí. Y en los estudios que sí he podido leer, no me queda claro en qué análisis de datos científicos se basan para tales afirmaciones. De momento, y a falta de otras pruebas más contundentes, debo fiarme del consenso científico que parece existir entre todos los autores especializados que he consultado.

Mi intención es darle al asunto un pequeño giro y añadir interacción en la narrativa: que los menores interactúen entre ellos y la historia la hará más suya. Para eso, una aventura conversacional puede ser, a mi modo de ver, una herramienta interesante.

Como puedes ver, efectivamente, estoy reinventando la rueda, incluso una que ya reinventé una vez. Supongo que habrá quien piense que podría haber utilizado el erlmud que ya tengo programado para el proyecto. Tendría que haberle hecho algunas modificaciones, para permitir escribir las aventuras, o haberlas escrito directamente en erlang y ya. Sin embargo, la idea es proporcionar la herramienta y que la gente tenga la posibilidad de utilizarla con sus propias aventuras, incluso que los chavales, con ayuda de algún profesor puedan hacer las suyas. No creo que erlang sea un lenguaje amable para iniciarse en la programación.

Con el proyecto de Trókola apenas había empezado, comprendía un par de comandos y quedó en barbecho: siempre me falta tiempo para todo lo que quiero hacer. Después de retomarlo, hace apenas unas semanas, sigue comprendiendo un par de instrucciones, pero he añadido el que se ejecute en modo servidor y responda vía telnet, el guardar/cargar partidas y el germen para el sistema de log. También he cambiado la licencia a una Affero GPL 3.0, para permitir su ejecución libre en un servidor.

Para la utilización en las aulas, puesto que me gustaría que fuera una herramienta educativa además de lúdica, el contar con el registro de todo lo que hacen los jugadores, y cuándo, para evaluar la actividad. De hecho, he pensado en hacer, cuando el proyecto esté más avanzado, una herramienta para analizar el log generado.

Debería ser lo último. Es decir, una vez que lo tienes todo funcionando haz que sea bonito. Sin embargo, a muchos les importa qué aspecto tiene la herramienta tanto más que su funcionamiento. Para muestra, un botón:

El aspecto visual es subjetivo y por tanto está sujeto más a gustos que a otras consideraciones. Las líneas generales, las mías, serían las siguientes:

• Simplicidad de la interface: sin menús ni barras de desplazamiento, mucho menos barra de herramientas.
• Tema oscuro de edición, pero con posibilidad de cambiar a uno claro para visualizar mejor en ambientes más luminosos, como la calle.
• Modificación de la línea de estado: información y diseño.
• Directorios, archivos, número de línea e iconos.

Por supuesto, se pueden añadir otros aspectos o eliminar algunos de éstos, como digo estas decisiones son cuestión de gustos. Por ejemplo, no me gustan las tabs para agrupar buffers, rompen el minimalismo de la interface y en su lugar utilizo el paquete perspective. Ya hablé sobre cómo organizar el espacio en una ventana de Emacs y también sobre algunos otros ajustes visuales. Puedes ir a esos artículos para tener más detalles.

La configuración de perspective es muy simple:

(use-package perspective
  :ensure t
  :init
  (persp-mode t))

Con perspective puedo cambiar entre distintas configuraciones de pantalla. Normalmente lo divido por tareas: en la perspectiva main suelo tener activas algunas tareas, como la agenda, la toma de notas, contabilidad y cualquier asunto más o menos trasversal. Luego, en otras perspectivas suelo cargar proyectos o tareas más específicas.

Más adelante en el apartado custom-set-faces modifico también el tipo de letra para resaltar la perspectiva con:

(custom-set-faces
 ...
 'persp-selected-face ((t (:foreground "yellow" :weight normal)))))

El cambio de perspectivas me permite tener varias configuraciones de pantalla sin los tabs, que estéticamente me parecen horribles.

Estos paquetes forman un conjunto imprescindible para mí. El primero de ellos es ivy. Proporciona un sistema de búsqueda y completado en el minibuffer que facilita la edición de comandos de Emacs y junto con los otros, especialmente counsel y swiper nos permite una flexibilidad maravillosa. La alternativa a ivy es helm, que sirve básicamente para lo mismo. Yo me encuentro más cómodo con ivy, pero es bueno saber que existen alternativas.

;; Configurar ivy
(use-package ivy
  :ensure t
  :init
  (setq ivy-use-virtual-buffers t
        ivy-height 15                             ; muestra 15 líneas de información (por defecto son 10)
        ivy-count-format ""                       ; no mostrar el contador
        ivy-initial-inputs-alist nil)
  :config
  (ivy-mode t))
;; Para utilizar iconos
(use-package all-the-icons-ivy
  :init (add-hook 'after-init-hook 'all-the-icons-ivy-setup))
;; Completa la información mostrada en forma de tablas
(use-package all-the-icons-ivy-rich
  :ensure t
  :init (all-the-icons-ivy-rich-mode t))
(use-package ivy-rich
  :ensure t
  :config
  (ivy-rich-mode t))

(defun ivy-rich-switch-buffer-icon (candidate)
  (with-current-buffer
      (get-buffer candidate)
    (let ((icon (all-the-icons-icon-for-mode major-mode)))
      (if (symbolp icon)
          (all-the-icons-icon-for-mode 'fundamental-mode)
        icon))))
;; Modifica la visualización de `ivy' en columnas
(setq ivy-rich-display-transformers-list
      '(ivy-switch-buffer
        (:columns
         ((ivy-rich-switch-buffer-icon (:width 2))
          (ivy-rich-candidate (:width 30))
          (ivy-rich-switch-buffer-size (:width 7))
          (ivy-rich-switch-buffer-indicators (:width 4 :face error :align right))
          (ivy-rich-switch-buffer-major-mode (:width 12 :face warning))
          (ivy-rich-switch-buffer-project (:width 15 :face success))
          (ivy-rich-switch-buffer-path (:width (lambda (x) (ivy-rich-switch-buffer-shorten-path x (ivy-rich-minibuffer-width 0.3))))))
         :predicate
         (lambda (cand) (get-buffer cand)))))
(setq all-the-icons-ivy-rich-icon t)
(setq all-the-icons-ivy-rich-color-icon t)
(setq all-the-icons-ivi-rich-icon-size 1.0)
(setq all-the-icons-ivy-rich-field-width 80)

El paquete counsel nos permite sustituir algunos comandos por homólogos. Sin embargo, puesto que lo utiliza ivy no tengo ninguna configuración especial para él, sólo me aseguro de que esté instalado y le añado una combinación de teclas para moverme por los documentos gracias a counsel-imenu o realizar un búsqueda en el buffer mediante grep:

(use-package counsel
  :ensure t)
(global-set-key (kbd "C-c g") 'counsel-grep)
(global-set-key (kbd "C-c m") 'counsel-imenu)

counsel proporciona bastantes comandos de sustitución, además de para grep o imenu, también puede gustarte el counsel-find-file u otros, es cuestión de probarlos y ver si te va bien asignarles combinación de tecla o no.

Como se muestra en la configuración, yo utilizo para buscar en el buffer que estoy editando con counsel-grep, para realizar la búsqueda (lo que es más rápido si es en un buffer grande) pero también, si el buffer es más pequeño, puedo utilizar la funcionalidad swiper.

swiper ni siquiera lo configuro. Se instala como dependencia de counsel de hecho. Lo descubrí por el comando counsel-grep-or-swiper, que utiliza una búsqueda u otra dependiendo del buffer abierto.

Por otro lado, hablando sobre búsquedas, hay veces que necesitas buscar en varios buffers. Para eso, suelo utilizar projectile-grep o bien project-find-regexp, pero esto lo hablaré en el apartado de programación, porque son herramientas enfocadas a esa actividad.

Otro paquete que utilizo bastante es yasnippet. Muchas de las tareas de edición presentan estructuras repetitivas, especialmente en programación, pero no sólo ahí y este paquete me proporciona, de manera sencilla plantillas que me ahorran bastante tecleo:

;; gestión de plantillas `yasnippet'
(use-package yasnippet
  :ensure t
  :defer t)

;; para que se entiendan `ivy' y `yasnippet'.
(use-package ivy-yasnippet
  :ensure t
  :defer t)

;; colección de plantillas para `yasnippet'
(use-package yasnippet-snippets
  :ensure t
  :defer t)

;; activar `yasnippet' automáticamente donde lo necesito
(add-hook 'org-mode-hook 'yas-minor-mode)
(add-hook 'prog-mode-hook 'yas-minor-mode)

;; asociar combinación de teclas para mostrar lista de snippets
(global-set-key (kbd "C-c y") 'ivy-yasnippet)

Otro paquete importante para mí es which-key. Uso Emacs a diario y, aún así, no consigo acordarme de todas las combinaciones de teclas que lanzan comandos en el editor. Sólo recuerdo algunas decenas de las que utilizo todos los días. A otras, de uso menos frecuente, accedo mediante la llamada a M-x <comando> y otras, me resulta más cómodo que Emacs (ivy en mi caso) me vaya soplando qué funciones tengo accesibles según la combinación que voy tecleando. Esa es la función del paquete which-key. Su configuración es sencilla, me aseguro de que está y lo tengo activado siempre:

(use-package which-key
  :ensure t
  :init
  (which-key-setup-minibuffer)
  (which-key-mode))

Hasta aquí, la funcionalidad general de Emacs para ejecutar comandos del editor, realizar búsquedas de texto o de comando y trabajar con plantillas que nos ahorran tiempo.

Hablo de alternativas porque últimamente se ha extendido entre los programadores la utilización de servidores LSP para la diversas funcionalidades implicadas en la escritura de código, convirtiendo el editor en un mero cliente de ese servidor. Emacs también proporciona entre los paquetes internos un cliente para este tipo de servidores: eglot. También existe otro paquete llamado lsp-mode que realiza funciones similares a eglot¹.

Si esa es tu forma de programar, descarga los LSP para los lenguajes que utilices habitualmente y configura eglot (para los lenguajes más habituales, seguramente no tendrás que hacer nada) y ponte a trabajar. En este blog también puedes encontrar información sobre eglot.

He probado LSP, pero al final no me ha convencido: dependes de una aplicación externa, que no siempre funciona porque tiene sus configuraciones y sus cadaunadas que me suelen molestar más que ayudar. Al final siempre vuelvo a modo clásico: configurar el editor para el trabajo. Por otro lado, tanto eglot como lsp-mode terminan tirando de los paquetes tradicionales: projectile o project para la gestión de proyectos, modos para coloreado de sintaxis e indentado, company o auto-complete para el autocompletado de términos, eldoc para mostrar la ayuda, etc. Es decir, si al final voy a utilizar esos mismos paquetes, ¿para qué voy necesito meter una aplicación externa haciendo de intermediaria?

Lo que me lleva a pensar: ¿Qué funcionalidades necesito en mi editor para programar?:

• Gestión de proyectos
• Coloreado de sintaxis
• Completado
• Ayuda en línea
• Comprobación de errores

Hecho el repaso general, como digo, muchos aspectos dependen de gustos. Cuando llevas un tiempo trabajando con un sistema tienes más oportunidades para hacer pruebas, ver si te convence más o menos una determinada herramienta. Al final son decisiones personales que tomas por motivos también personales.

Espero que este artículo pueda servir a quien se introduce en Emacs a tener una perspectiva general sobre la configuración. Algo que a muchos puede parecer abrumador, dada la cantidad de opciones, detalles y aspectos que se pueden ajustar.

Seré breve. Encontré un paquete en Melpa que se llama plisp-mode y otro para autocompletado company-plisp. Los instalé los dos siguiendo sus correspondientes documentaciones. El código es sencillo:

(use-package plisp-mode
  :defer t
  :init
  (require 'inferior-plisp)
  :custom
  (plisp-documentation-unavailable t))
(use-package company-plisp
  :defer t
  :after company)
(add-to-list 'auto-mode-alist '("\\.l$" . plisp-mode))

Hay que tener en cuenta las siguientes aclaraciones. Tengo la instalación de PicoLisp de manera local. El paquete plisp-mode busca la documentación de manera global así que me aparecía constantemente un error por no encontrarla y desactivé la búsqueda de la misma activando la variable plisp-documentation-unavailable. También hice otras pruebas creando los enlaces necesarios para convertir la instalación local en global y seguía sin encontrar la documentación. Sin embargo, en la línea de comandos la documentación está disponible cuando inicias PicoLisp en modo debug.

Para leer la documentación desde línea de comandos, por tanto, hay que lanzar el REPL en modo depuración. El sistema leerá los html que componen la documentación utilizando el navegador w3m. Por ejemplo, llamando a la función (doc 'de), nos mostrará el contenido de la documentación de dicha función, llamando a dicho navegador de modo texto. w3m es, por tanto, una dependencia si quieres acceder a la documentación desde pil.

Por último, la convención dice que el código de PicoLisp se encuentra en archivos con extensión .l y añado dicha extensión, asociándola a plisp-mode en la lista de modos.

Es evidente la sintaxis de tipo Lisp con sus paréntesis en danza, pero para un programador de este tipo de lenguajes tiene pocas más semejanzas y hacerse una idea de lo que hace le obliga a utilizar su imaginación. Algunas funciones parecen sonar setq, loop... pero de en lugar de define, que admite una lista de parámetros con el formato Lst en lugar del habitual (...). Variables que comienzan con *, como *Name, mientras que otras no, como Lst. Es decir, hay un montón de idiosincrasias que hay que tener en cuenta.

La primera bofetada fue por su forma de establecer las variables. Lo de utilizar la primera letra en mayúsculas, por convención, pues tampoco es que me llame mucho la atención, o utilizar * para señalar las variables globales mediante un prefijo simple. Pero quizá algún programador de Lisp o Scheme entenderá mejor lo que quiero decir con este código:

: (setq A '(Este es su valor))
-> (Este es su valor)
: (put 'A 'clave1 'valor1)
-> valor1
: (put 'A 'clave2 'valor2)
-> valor2
: (show 'A)
A (Este es su valor)
   clave2 valor2
   clave1 valor1
-> A 

Sí, se pueden meter pares clave-valor como parte de cualquier «variable». Se introducen con put y se extraen con get. Más adelante veremos que tiene que ver con cómo se definen los símbolos dentro de la máquina virtual. Pero de primeras me sonó marciano.

Se puede apreciar que la definición de variables se utiliza setq, también las podemos definir con de, aunque con su propia idiosincrasia:

: (de ho "hola")
-> ho
: ho
-> ("hola")
: (ho)
-> NIL
: (de ho . "hola")
# ho redefined
-> ho
: ho
-> "hola"

La primera versión de ho, en ese código, puede no ser la deseada. De momento me ciño a utilizar setq para las variables y de para las funciones, para no liarme.

Luego me llevé otra bofetada aún más gorda con los números. Leí, así de pasada, que soportaba sólo operaciones de coma fija, por lo que hay que especificar el número de decimales cuando los necesitas. Bueno, no es algo extraño y ya lo había vivido en otro tipo de sistemas, como la calculadora de línea de comandos bc, pero el choque con la realidad fue un poco más traumático.

? (+ (* 3 4) 1)
-> 13
? 
: (/ @ 3)
-> 4
: (scl 3)
-> 3
: (+ (* 3.0 4.0) 1)
-> 12000001

¿Cómo? ¿Qué está ocurriendo? Pues sí, a los números hay que darles un poco más de cariño.

La cantidad de decimales se almacena en una variable global que se llama *Scl y podemos establecerlos con la función scl, como se aprecia en el código anterior. Pero se puede ver que internamente 3.0 se convierte en 3000 y 4.0 en 4000, al establecerse tres posiciones decimales. Y, por esto mismo, al multiplicar los números el resultado es 12.000.000, o expresado de otro modo: al multiplicar \(3 \cdot 10^3 \times 4 \cdot 10^3\) el resultado es \(12 \cdot 10^6\). Es decir, PicoLisp no tiene en cuenta automáticamente los decimales, sino que mantiene los enteros, pero escalados.

Con las sumas y restas no hay problema, porque los números cuando tienen una escala, se mantienen dentro de la escala, pero en las multiplicaciones y divisiones hay que compensar la escala. Para ello se utiliza la función */, que recibe tres parámetros numéricos y multiplica los dos primeros para luego dividir el resultado por el tercero. Por lo tanto, se utiliza la multiplicación o división por 1.0 para mantener la escala en orden:

: (+ (*/ 3.0 4.0 1.0) 1.0)
-> 13000
: (*/ 1.0 13.0 4.0)
-> 3250
: (format (*/ 1.0 13.0 4.0))
-> "3250"
: (format (*/ 1.0 13.0 4.0) *Scl)
-> "3.250"
: (format "3.25" *Scl)
-> 3250
: 

Después, se puede contar con la función format para convertir números en cadenas y cadenas en números.

Al principio, toda esta movida me parecía un sindiós. Luego, me puse a mirar cómo funciona el chismático y encontré los porqués y las explicaciones a todas estas idiosincrasias. Aunque estuvieron a punto de echarme para atrás.

Puesto que las primeras aproximaciones fueron un poco frustrantes, lo siguiente que hice es echar un vistazo a la documentación buscando por qué estaba pasando lo que pasaba. Os hago un resumen de lo que encontré y cómo funciona la máquina virtual de PicoLisp, que soporta los siguientes tipos de datos:

En base a la definición básica de cell, soporta:

• Los tres tipos de datos básicos: Números, símbolos y listas.
• Los tres tipos de símbolos: Internal, Transient y External.
• El símbolo especial NIL.

Un tipo de dato cell se define, como se ve en la siguiente imagen, en un conjunto de CAR y CDR. Algo que es común en los lenguajes Lisp.

El código se guarda en símbolos internos. Una definición de una función lo que hace es crear un símbolo cuyo valor es el código. No hay, por tanto, diferencia entre el tratamiento del código y de los datos, son equivalentes.

Para definir una función se utiliza normalmente una llamada a la función de:

: (de hola ()
   (prinl "¡Hola Mundo!"))
-> hola
: (hola)
¡Hola Mundo!
-> "¡Hola Mundo!"
: 

Pero el resultado sería idéntico si utilizamos setq:

: (setq hola '(() (prinl "¡Hola Mundo!")))
-> (NIL (prinl "¡Hola Mundo!"))
: (hola)
¡Hola Mundo!
-> "¡Hola Mundo!"
: 

Otro de los problemas, que me encuentro frecuentemente al escribir código, es el interpretar el ' como en Lisp o en Scheme. En PicoLisp el quote se aplica a toda la lista, no sólo al primer elemento. Esto me desconcertó un poco al principio y aún no me he acostumbrado del todo. Aunque también he aprendido que se puede forzar la evaluación de alguna expresión interna utilizando el carácter ~.

: '(1 (+ 2 3) 4)
-> (1 (+ 2 3) 4)
: '(1 ~(+ 2 3) 4)
-> (1 5 4)
: 

No hay macros explícitas, porque cualquier función puede devolver una cadena de texto, que si mantiene la sintaxis de PicoLisp, está generando código como lo haría una macro. Si vas a utilizar metaprogramación es conveniente que le eches un ojo antes a cómo evalúa el código la máquina virtual de PicoLisp.

Tampoco hay una expresión lambda, pues, como hemos visto al utilizar una función setq para definir una lambda, se puede generar una función anónima simplemente con quote:

(setq hola (quote () (prinl "¡Hola Mundo!")))

O por ejemplo:

: ('((X) (* X X)) 3)
-> 9
: ((quote (X) (* X X)) 9)
-> 81
: (setq f '((X) (* X X) ) )
-> ((X) (* X X))
: (f 3)
-> 9
: 

Si te molestan mucho los paréntesis los puedes agrupar utilizando [ y ]. Por ejemplo, la definición anterior la podríamos haber definido también como:

: (setq f '((X) (* X X]
-> ((X) (* X X))
: (f 3)
-> 9

Estos son los ladrillos básicos de PicoLisp. Algunos me ha costado cierto trabajo digerirlos, sin embargo, ha sido más por tener los procesos mentales acostumbrados a otro tipo de sistemas. Aún cometo muchos errores cuando escribo código, precisamente por esto. Aunque comencé estrellándome, confiado en mi conocimiento de Common Lisp y de Scheme, al mirar cómo está hecha la máquina virtual y «los ladrillos» de este sistema, me fue más fácil interiorizar cómo funcionan la cosas y cometer menos errores.

A partir de estos chismáticos básicos, PicoLisp proporciona algunas características interesantes, que dejo para futuros artículos:

• Soporte nativo de Programación Orientada a Objetos.
• Base de Datos orientada a almacenar objetos POO.
• Lenguaje de consulta de la BD basado en Prolog.
• GUI basado en html y su correspondiente servidor de aplicaciones.
• Sistema de debug incorporado
• Editor de código interno basado en vi.

Este año empezó con bastante actividad por este blog, tenía bastante tiempo y hubo meses con más de un artículo semanal. Sin embargo, después de verano mis otras obligaciones me desaparecieron prácticamente el tiempo libre o las ganas de sentarme a escribir. Mucha reunión, mucho desplazamiento y mucho desgaste intelectual hicieron que cuando llegaba a casa no me apeteciera sentarme a estrujarme la sesera para trastear con algo y ponerlo por escrito en este blog.

Como resumen general queda el trasteo de un poco de vaporware con algún lenguaje de programación minoritario (de los que me gustan a mí), como el programa de ajedrez, que al final se quedó en proyecto inconcluso. Pero también está, esta vez sí cumplido, mi propósito de ampliar mis conocimientos de LISP y sus derivados, como Scheme. No sólo eso, sino que también he probado algunas otras herramientas que debo profundizar. De momento, entre los LISP tengo el «corazón partío» entre SBCL y ECL, aunque entre los Scheme sí me he decantado por Chicken Scheme.

Este año que viene se plantea algo más movido aún en otros ámbitos y no sé cuánto tiempo me quedará para el blog. A través del proyecto de Hispa-Emacs se quiere aglutinar en lo posible la información sobre Emacs que se realice en español. Junto con Fénix y Maxxcan espero la resurrección del perdido planet-emacs.es. Maxxcan tiene ya comprado el dominio y solicitó ayuda para ponerlo en marcha, así que mi intención es poder echar una mano también con ese proyecto de relanzamiento.

Con respecto a Hispa-Emacs la idea es generar una página web estática con información, cursos y una colección de vídeos, en Fediverse.tv, sobre Emacs. También, para realizar todo el código que necesitemos, se ha creado un grupo en Codeberg para alojar los repositorios necesarios de Hispa-Emacs. De momento Fénix y yo somos los dos únicos voluntarios, pero si estás interesado en participar ponte en contacto con nosotros para ver si conseguimos montar un buen grupo de trabajo.

Por supuesto, está por ver dónde acaba toda esta iniciativa, pero mi intención es dedicar tiempo (y código) a ello. Pero, sobre todo, sin abandonar este blog, aunque quizá encontréis contenido cruzado y alguna repetición de trasteos si sigues ambas iniciativas. Mi tiempo no es infinito.

También, para el año venidero tengo pensado profundizar un poco más en una herramienta que ya he mencionado en el blog: PicoLisp. ¿Por qué? Pues básicamente porque aunque no es un LISP —al menos, no un Common Lisp como sbcl o ecl lo son—, tiene una sintaxis parecida a la familia. Además cuenta con algunas otras características que lo hacen interesante para mí: tiene un montón de chismáticos con los que me gusta trastear:

• Sintaxis: estilo LISP, que ya lo he comentado, aunque me parece un chismático más parecido a Scheme.
• Multiparadigma: tanto POO, funcional, características de Prolog
• Base de datos integrada: sí, tiene una base de datos integrada en su máquina virtual (lo que me recuerda a la que tiene también erlang).
• No es multihilo pero los procesos se pueden comunicar entre ellos (¿será parecido a como lo hacía erlang?)
• Aunque no cumple, estrictamente, con las características de los lenguajes funcionales, como la inmutabilidad de las variables, sí provee todo el armamento de acceso, mapeo y trabajo con listas que tienen los familiares de LISP.
• Interoperatividad con otros lenguajes como c o java.
• GUI incluido en la especificación del mismo lenguaje. En sus primeras versiones el GUI estaba proporcionado por java, pero en la actualidad se utiliza html montando un servidor local. Por lo que se convierte en un candidato a tener en cuenta si lo que quieres es hacer una aplicación web, proporcionando base de datos y servidor dentro de la misma máquina virtual.
• REPL, interactividad. Ya sabéis lo que me gustan a mí los lenguajes «repelentes».

Por tanto, amenazo, como tantas otras veces que me he puesto a aprender alguna de estas tecnologías rarunas, en buscarme una aplicación que desarrollar y cansinaros con el desarrollo, mientras aprendo cómo funciona el chismático.

Si estás interesado en Emacs y su mundo, sigue atento a este blog y a Hispa-Emacs. Cuando haya algo más concreto con planet-emacs avisaremos en ambos espacios. Y no olvides, que también puedes participar: para ello, ponte en contacto con nosotros y entra en nuestras reuniones virtuales. Cuantos más seamos, más nos divertiremos. Si eres usuario de Telegram puedes entrar también en el grupo de Emacs-orgmode en dicha red para poder enterarte de las cosas cuando se están produciendo.

Nos vemos este año que viene.

Ahora mismo tengo instalados tres sistemas de notas en Emacs, que están conviviendo de aquella manera y que mantendré hasta una charla que tengo prometida para un vídeo de los de hispa-emacs sobre la toma de notas. La convivencia de los tres paquetes se hace un poco pesada a estas alturas y estoy deseando eliminar el lastre en la configuración.

Mantendré deft, porque la visualización en tabla y la búsqueda rápida de contenido me parecen bastante buenas. He probado el paquete denote-menu, pero la funcionalidad del mismo es bastante pobre.

El ingenioso arte de mantener los tres sistemas va de la siguiente manera:

Debo reconocer que org-mode me ha malacostumbrado, con él puedes hacer de todo y algunas herramientas se me hacen, a estas alturas imprescindibles. Tanto, que el proyecto de crear mi propio sistema de notas se percibe tan complejo como el propio org-mode y por tanto, tan desafiante y lleno de aprendizajes que me estoy planteando seriamente hacerlo.

De momento se podría decir que con estos sistemas tengo la mayoría de mis necesidades cubiertas. Sin embargo, para algunas cosas he de tirar de herramientas externas al propio Emacs y org-mode... como decía Extremoduro: salir, entrar, el royo de siempre.

Lo que necesito, son unas pocas cosas:

1. Gestión de calendario. Algo que para concertar citas es fundamental, y una vez me he acostumbrado a la agenda de org-mode y a cambiar de vista con una tecla, me resultan innecesariamente complejos otros sistemas.
2. Gestión de tareas periódicas. Como autónomo, la presentación de IVA e impuestos trimestrales u otras tareas periódicas, como el programa de radio, el repaso semanal a la contabilidad, etc. Aparecen en mi agenda de forma automática y además las puedo marcar cuándo las hago y llevar un registro de cuándo hice qué cosa.
3. Control de tiempos. Algunas de las tareas que realizo las cobro por horas, por lo tanto, el cronometrar cuánto tiempo invierto en ello me facilita luego la facturación. Esto es algo que ya apareció en este blog y no hace falta repetirlo. Lo hace org-mode de una manera sencilla.
4. Notas cifradas. En mi trabajo la confidencialidad es una de las necesidades básicas del día a día. Poder tener notas cifradas sobre mis clientes y sus problemas, es básico para mí. Basta con terminar el nombre del archivo de la nota con .gpg para que se cifre automágicamente.
5. No sólo texto. Las anotaciones, efectivamente, suelen ser de texto, sin embargo, algunas veces necesito adjuntar algún gráfico, como los perfiles de tests y otros adjuntos, como archivos pdf, por poner un ejemplo. Emacs además proporciona las suficientes herramientas para visualizar casi todos los tipos de adjuntos.
6. Separación de notas. Cuando te dedicas a una sola cosa, parece buena idea tener todas las notas en el mismo sitio. Sin embargo, me dedico a varias actividades independientes y por tanto necesito que no se me mezclen las anotaciones. Especialmente las que se refieren a facturación, pues unas llevan IVA y otras —las clínicas y las educativas— están exentas de ese impuesto. Además, las notas sobre las sesiones con clientes están en un disco duro externo cifrado y no se deben mezclar con otro tipo de notas.
7. Accesible desde distintos dispositivos. El problema viene, normalmente, de acceder con otros sistemas operativos, como por ejemplo, Android/®. Cuando salgo por ahí, no suelo llevar el ordenador más que contadas veces, como cuando voy a hacer el programa de radio, y es más cómodo trasladarme con una /Tablet barata que no me supondrá demasiada pérdida si se estropea o le pasa algo.

De todos estos puntos —seguro que ahora mismo no caigo en algún requisito más—, el más complejo es el 7. El resto (y mucho más) lo hace org-mode por nosotros sin despeinarse. El asunto de tener varios dispositivos con las notas sincronizadas es lo complicado y he utilizado varias aplicaciones y métodos para hacerlo, como aplicaciones de sincronización, nube. En la actualidad estoy optando por tener un repositorio, al fin y al cabo, las notas en su mayoría son texto plano. Además, sigo teniendo mi nube prsonal, en mi sitio web, mediante NextCloud y me permite compartir datos, como el repositorio, porque es un fichero fossil.

Si te preguntas por qué utilizo fossil y no git la respuesta tiene varias vertientes. La primera es que un repositorio fossil es monolítico —un fichero sqlite con todo dentro— y eso nos da alguna ventaja al compartirlo por NextCloud. O dicho de otro modo: uno de los problemas que me encontré cuando lo intenté con git es que los cambios de un repositorio git se almacenan en archivos sueltos dentro de un directorio oculto del sistema. Además NextCloud se lleva mal con los archivos y directorios ocultos y no siempre sincroniza correctamente, sin contar con las ocasiones en las que hay colisión entre las versiones de los distintos dispositivos. Alguna vez me encontré el repositorio totalmente inservible por efecto de una mala sincronización, pues cuando hay conflicto en NextCloud suele añadir archivos duplicados para no borrar nada. Si no estaba atento a los errores de sincronización y abría git, la aplicación se encontraba con que el repositorio tenía elementos extraños que no sabía cómo manejar.

Por otro lado, aunque con fossil también hay conflictos, pero, el resultado es mucho más manejable. Si ha habido algún choque de versiones se mantiene el archivo anterior y añade el elemento extraño. El efecto resultante es que el repositorio no se ha actualizado, no hay error ni se corrompe el log. Simplemente, vas a NextCloud solucionas el error y actualizas de nuevo con fossil update.

Lo dije antes: llevo tiempo queriendo hacer una aplicación sencilla que cumpla con todas mis necesidades en el ámbito de la toma de notas. ¿Para qué? Pues para aprender. A eso se le juntan las ganas de aprender PicoLisp, un lenguaje minimalista de la familia de los LISP. Aunque no hay necesidad a estas alturas, porque tengo montado un sistema de mínimo esfuerzo juntando distintas piezas de terceros: Emacs, org-mode, denote, deft, NextCloud, Termux (para Android®) y fossil.

¿Por qué PicoLisp? A parte de que es un lenguaje similar a LISP o Scheme, tiene unas características minimalistas de las que siempre me resultan interesantes: integra, en una máquina virtual muy reducida, una base de datos y soporte para GUI. Además, para Android® existe una aplicación llamada PilBox que ejecuta scripts de PicoLisp directamente en ese sistema operativo. Por otro lado, también puedes usarlo desde Termux, porque es uno de los paquetes que puedes instalar en esa maravillosa «minidistro» integrada en Android®.

El objetivo, como he dicho antes, no es crear el más maravilloso sistema de notas, sino aprender. Necesitaré bajar a definir qué es una anotación, de qué partes se compone, cuáles son sus características y comprender así un poco mejor algunos algoritmos básicos y manejar listas, árboles, propiedades y, por supuesto, sus enlaces y valores.

Tardaría menos haciendo un pequeño paquete de Emacs, que subiéndose a hombros de gigantes, consiguiera realizar aquello (poco) que echo a faltar en el sistema que tengo montado ahora, pero con elisp ya me manejo y no aprendería demasiado.