¿Preparando la NaNoWriMo?
También podría haberlo titulado poniéndole los cuernos a Emacs, pero no es cierto. Emacs sigue estando en el ajo, aunque sólo sea como editor. Pero vamos al grano: Algunas veces hablo de mis proyectos vaporware como si fueran realizables o casi. En este caso, este vapor silba desde hace ya unos cuatro años. Por aquí, ya había comentado que trokola alcanzaba su versión alfa, y quería usarlo para generar aventuras conversacionales multijugador para utilizarlas en un Plan de Prevención del Acoso Escolar que ando perpetrando para la Asociación con la que colaboro como voluntario. Hecho el programa, necesito historias que faciliten la ambientación de las aventuras. Y ¿cómo consigo esas historias? Pues no me queda más remedio que escribirlas yo.
No me malinterpretes, me gusta escribir, si no fuera así, por qué iba a mantener un blog. Otra cosa es que lo haga bien, mal o regular. Que supongo que irá en gustos, esto es, si tienes mal gusto a lo mejor te gusta lo que escribo, no sé. Hasta ahora, las cosas que he ido escribiendo me las he ido guardando. Algunas de ellas, esas de las que el escritor1 parece sentirse orgulloso, las he enseñado a los amigos y allegados. Pero dicho que me gusta escribir, debería contestar también si voy a hacer la NaNoWriMo, porque al menos, la menciono en el título del artículo, y la respuesta es no, no voy a meterme esa pechá de escribir para nada. Además no necesito una historia larga, sino varias más cortas en las que aparezcan puzles y retos que superar con un poco de inteligencia y un bastante de colaboración de grupo.
Necesito organizarme, y de esto va hoy el artículo, de contaros cómo me voy a apañar el trabajo.
Organización
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.
Plantillas
Las plantillas están escritas en M↓ así que, en general, el proyecto
irá en ese lenguaje de marcas. Cuando necesite crear un elemento de la
historia, accederé al Wiki y copiaré el contenido de la página en un
archivo que luego irá al repositorio.
Al inicio de escribir la historia generaré unos pocos documentos que se irán actualizando según avance el trabajo. Por ejemplo, el cuadro resumen que me permitirá de un vistazo ver cómo va el desarrollo:
También será interesante tener la ambientación, aunque aún no tengo claro si esto irá en el mismo fichero, o saldrá más a cuenta tenerla en un directorio y cada aspecto relevante tratarlo en un archivo independiente:
Por supuesto, para las tramas, las escenas y los personajes cada una irá en su ficha correspondiente.
Cada uno de estos tres grupos de fichas irán en su correspondiente directorio para que no se me mezclen las churras con las merinas. Además de esas fichas había pensado en utilizar el foro incorporado en Fossil para anotar, en hilos específicos para cada asunto, ideas o inspiraciones que vayan surgiendo según trabajo, para nuevos personajes, para nuevas tramas o escenas, para nuevas historias.
En el caso de los personajes, además pueden ir complementados con algunos detalles que les den algo de profundidad. No sólo porque utilizaré también la herramienta Pikchr para generar su genograma2, sino también otro tipo de información menos habitual.
Contenido
Evidentemente, el contenido irá aparte, en su directorio. Aún no he
decidido si irá todo junto o habrá subdirectorios por capítulos.
Además en el CSS he añadido alguna funcionalidad para que la
visualización sea más agradable. En las capturas anteriores podéis
observar notas explicativas de cómo hacer algo, pero también hay
avisos, que aparecerán en rojo para advertir de peligros o errores que
hay que corregir. Otro tipo de notas aparecerán en gris y pueden ser
sugerencias o ejemplos de texto que hay que considerar si incluirlo o
no.
Por último, también a través de CSS se ha implementado un método de
marcado de texto, como si lo subrayáramos con el clásico iluminador
fosforito que puede llevar aparejado, o no, una nota al estilo pósit.
Esto, creo que me será útil cuando esté haciendo la revisión de los
textos.
¿Cómo funcionará el asunto?
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.
Generar el contenido
Para la generación del contenido seguramente utilizaré Pandoc para la
conversión de los archivos M↓ en html. Pero hay un problema: El
intérprete de M↓ que viene integrado en Fossil no es del todo
estándar, tiene algunos añadidos que no están en otros intérpretes,
algo que suele ocurrir con estas herramientas. Aún no tengo claro si
esto me hará añorar mi amado org-mode o no, a unas malas, no deja de
ser texto plano y lo mismo puedo hacer algún script que coja las
partes no estándar y las convierta. En principio, en los archivos
definitivos no debería ir nada que no sea texto sencillo.
La idea primigenia es hacerme un Makefile que genere los html por
capítulos o un script en otro lenguaje que lo haga llamando a Pandoc.
Conclusión
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.
Notas al pie de página:
Obsérvese al pedante hablando de sí en tercera persona... ¡Ejem! ¡Lo hice de nuevo!
Un genograma es una representación gráfica de la estructura familiar de una persona donde se pueden añadir informaciones relevantes sobre eventos importantes para la familia y mediante códigos gráficos, mostrar las relaciones entre sus miembros.
Comentarios