Último día del OCC.

Como repunte, hoy expondré las razones por las que Emacs
me gusta pero a la vez me echa para atrás.

Es un buen entorno y la documentación en inglés es quizá
la mejor existente de todo el proyecto GNU de lejos.

Se puede ir a la ayuda de la función con
M-x describe-function
y también hay facilidades para ir directamente
al nombre de uan librería. Eso es bueno;
y el poder reutilizar código Elisp de otros módulos
(translate de telega, música de Emms, SHR
del navegador para leer Epubs) se hace un sistema
sin igual.

Pero tiene un pero: Emacs es monohilo. Si la E/S
de algo bloquea el editor, te bloquea todo; salvo
subprocesos Unix que operen de forma asíncrona y
no necesiten llamar a Emacs para nada. Por ejemplo,
mpv abierto para ver películas o música desde EMMS.

Y, sobretodo, la latencia es notable,
comparado con TMUX+Slrn y amigos,
al volver a xterm la velocidad
es sobrehumana, como user un electrodoméstico.

Eso siempre me ha fastidiado. Por supuesto si se
rehiciese el editor lanzando un proceso Elisp
por cada programa, como por ejemplo GNUS, se perdería
el poder llamar a funciones comunes con total facilidad.
De ahí que nacieran cosas como OLE y demás como DBUS en
Unix para compartir principalmente objetos, pero
no código compartido. DBUS palidece frente a poder
usar por ejemplo M-x calc dentro de tu chat o
el correo para calcular fechas, distancias entre
coordenadas GPS, cálculo científico y 2000 locuras
más sin salir del editor. Ojalá solventasen eso.
Existe el Emacs con compilación nativa pero en i386
y OpenBSD, nada de eso es posible.

Por lo tanto, para evitar condiciones de carrera,
la solución idónea sería hacer de GNUS (solo GNUs)
multiproceso o multihilo en su propio proceso
Elisp, al menos la función de procesado
de cabeceras, donde se puede hacer 
en paralelo y ordenarse al final.
No sé si GNUs usa objetos o demás por debajo,
pero huiría como de la peste de cualquier
anidación larga de conses para clasificar
el correo con ello. 

También, probé por un poco el EDE (Emacs Development
Environment), una especie de IDE hecho en Emacs.
Es bastante obtuso y 'horrible' de usar.
Un makefile es mucho más amigable y directo.
La gente suele usar Treemacs+LSP, así que
si lo mejor desbanca a lo viejo, lo mejor
es aprovecharlo.

En Emacs se usaba RMAIL con formato Babyl
(similar a MBOX en Unix) y como cualquiera
puede comprender el acceso lineal a cabeceras
de correo en un solo fichero es un suicidio.
El formato Maildir, donde deja un solo
fichero por correo en un directorio es muy superior.
Leer el inicio de un fichero en un sistema de ficheros,
donde ya hay referencias y mejor optimizadas
que el acceso lineal es miles de veces más rápido.
Por alguna razón GNUS no lee bien Maildir, pero
si solventan eso, ya tienen el 90% de usuarios de
correo ganados sin tener que usar Mu y Mu4e.

Lo mismo con Usenet, pero extrañamente es peor.
En directorios con más de 10000 ficheros, incluso
no ya conectándote con NNTP, si no con
un 'spool' de SLRN el acceso demora segundos y
cuando no minutos. Es aberrante la lentitud de GNUS
cuando SLRN tarda milisegundos en una máquina
con CPU n270 como ya dije.

Entiendo que ELISP es decenas de veces más lento que C
pero no debería ser miles de veces más lento.

Lo que es peor, GNUS puede bloquear tu máquina mientras
indiza los ficheros de noticias o correo.
Lo mejor es correr un segundo Emacs con GNUS dentro
aunque se pierdan funcionalidades.

Finalmente, una nota positiva: Telega es el único
cliente donde se puede usar tanto en modo texto
como gráfico sin levantar megas o gigas de
RAM como una solución QT5. La web JS es inviable
en este netbook. Si se configura bien, se puede
hasta usar ffmpeg creo para hacer videollamadas.
Y de momento me han funcionado videos con mpv
e imágenes con el visor interno.