Lo que he aprendido: centralizar archivos de autoguardado de Emacs

¡Hoy traigo un truquillo rápido! Como sabéis Emacs va dejando por ahí copias de seguridad (archivo~) y archivos de autoguardado (#archivo#) de lo que abrimos y editamos. Esta es una funcionalidad que me ha salvado el pellejo en más de una ocasión pero no me gusta tener mierdecillas extendidas por todo mi ordenador. Hoy por fin he descubierto como mandarlos todos a otra carpeta, en concreto a la carpeta temporal. Para ello he añadido lo siguiente al archivo de configuración:

(setq backup-directory-alist
`((".*" . ,temporary-file-directory)))
(setq auto-save-file-name-transforms
`((".*" ,temporary-file-directory t)))

Para averiguar dónde anda la carpeta temporal hacemos C-h v (Describe variable) y le decimos que describa temporary-file-folder. También se le puede dar otra ruta que nos parezca más adecuada, claro.

Al loro porque usamos acentos graves y no apóstrofes en este caso porque solo queremos que cite las cosas que van antes de la coma, no hagáis como yo que estaba convencida de que había copiado mal y no entendía por qué no funcionaba.

Lo interesante del tema es que aunque mandemos los archivos a otra carpeta seguimos recuperándolos como de costumbre con M-x recover-file. ¡Qué listo es Emacs!

Por cierto, aparte de estos, hay unos archivos de interlocking que aparecen al abrir un archivo y cuyo nombre empieza por .# seguido del nombre del archivo abierto. Sirven para evitar que dos programas editen el archivo al mismo tiempo y no tienen nada que ver con estos que tratamos hoy. ¡No nos liemos! (Como ya he hecho yo)

Bueno, pues no os cuento nada más por hoy, estamos pronto.

Referencias

Keep Backup and Auto-save Files Out of the Way

GNU emacs backup files

18.3.4 Protection against Simultaneous Editing en el manual de Emacs


Grupos que descubro gracias al Sótano 😀

Anuncios

Lo que he aprendido: la nube como repositorio remoto

Después de commitear 600MB en imágenes de Matlab pensé que algo había que hacer si no quería romper GitLab, que ya se rompe bastante por sí solo. Estuve jugando con los interiores de git y me divertí mucho, pero finalmente decidí dejarlo, eliminar el repositorio y hacer uno nuevo decentemente. Ahí fue apareció el blog de Notxor con su flamante nueva entrada sobre git. Resulta que él en lugar de usar un servicio del estilo de GitHub tiene su propio repositorio remoto en su nube, en este caso una Nextcloud. ¡La solución a mis problemas de espacio!

Veamos cómo he adaptado el proceso a mi caso.

El repositorio central

He optado por utilizar como remoto una carpeta que tengo sincronizada en el Google Drive mediante la herramienta Copia de seguridad y sincronización ya que en el currelo tenemos mucho almacenamiento en el Drive (lo que tiene venderle tu alma a Google).

Ahí he creado un repositorio bare, es decir, uno en el que no hay árbol de trabajo. En un repo de este tipo en lugar de haber una carpeta .git con las movidas de git y luego nuestro archivos, hay solo lo que suele haber en la carpeta .git a pelo. La idea de esto es que sea un repositorio central, no uno donde se trabaja. Así, los colaboradores enviarán allí su código (push) y recuperarán los cambios (fetch/pull).

Para crear uno que se llame repo.git hacemos:

git init --bare repo.git

Se suelen apellidar .git para diferenciarlos de los repositorios normales y corrientes.

El repositorio de trabajo

Ahora que ya tenemos creado el repo remoto nos queda configurar el local. Aquí tenemos varias alternativas dependiendo de la situación en la que estemos

  • Si no hemos empezado a currar todavía, clonamos el repo vacío en algún punto de nuestro ordenador. Nuestro repo clonado sí tendrá árbol de trabajo:
git clone RUTA/repo.git 
  • Si ya tenemos el repo local, pero no hemos establecido el remoto:
git remote add NOMBRE RUTA/repo.git
  • Si es un repo cuyo remoto es otro y queremos cambiarlo o añadir uno adicional:
git remote set-url NOMBRE RUTA/repo.git

Ahora ya podemos funcionar normal entre ambos repositorios, igual que si estuvieran en GitLab y el Drive, Dropbox, Nextcloud o lo que sea se encargará de sincronizar nuestros repo central.

¡Muchas gracias a Notxor por compartir lo que sabe con todos nosotros! 😀

Referencias

Cómo estoy utilizando git en el blog de Notxor

How do you use “git –bare init” repository? en StackOverflow

What is a bare git repository?

git init en el manual

Push to only bare repositories

Using Git and Dropbox together effectively? en StackOverflow1


Mientras escribía oía:


  1. ¡Gracias a Notxor por el enlace! 

Lo que he aprendido: personalizando cosillas en org mode

¡Estoy a tope con el modo org! Me hace ser más eficiente y organizada y eso que todavía no le he sacado mucho jugo. Hoy quería poner por aquí algunas opciones de configuración para el modo org que he añadido a mi archivo de inicio de Emacs. ¡Así me contáis cómo hacéis vosotros!

Todos ellas las he activado con setq que en mi proceso de entender lo que copiopego de Internet en mi archivo de configuración he descubierto que asigna valores a variables y que el típico t significa True y el nil False. En fin, ¡veamos cosas!

Modo indentado

Lo primero que he activado es el modo limpio o indentado, es decir, el que en lugar de ponernos estrellitas para los encabezados nos los indenta según su nivel para que veamos todo más claramente. Con él activado nosotros escribimos como siempre y org nos organiza las listas, los títulos y demás. Bastante útil.

Se activa estableciendo org-startup-indented como True:

;; Modo indentado
(setq org-startup-indented t)

Fecha de cierre de las tareas

Otra opción que he activado es que me aparezca cuándo he cerrado una tarea al pasarla al estado DONE:

;; Marcar fecha de tarea realizada
(setq org-log-done 'time)

Ahora cuando voy hasta DONE con C-c C-t debajo me aparece una línea en la que pone CLOSED y la fecha de conclusión en morado.

Cambiar la secuencia de palabras clave

Como tener solo estados de TODO y DONE me parecía poco para organizarme, he añadido dos más: un CHECK para las tareas que están hechas pero requieren algún tipo de verificación o corrección externa, y CANCELLED para las tareas que por algún motivo no seguirán adelante pero que quiero tener localizadas.

Podría añadir estas palabras clave en los archivos en que las necesite pero como me parecen útiles he oreferido añadir la configuración directamente en el archivo de inicio:

(setq org-todo-keywords
'((sequence "TODO" "CHECK" "|" "DONE" "CANCELLED")))

Gracias a estas líneas al hacer C-c C-t se rula por esos estados.

Asignar colores a las palabras clave

Una vez generadas palabras claves nuevas pensé que estaría bien asignarles colores. Para ello se usa la variable org-todo-keyword-faces con algún color que Emacs entienda:

(setq org-todo-keyword-faces
'(
("TODO"   . (:foreground "firebrick2" :weight bold))
("CHECK"  . (:foreground "orange1" :weight bold))
("DONE"   . (:foreground "forestgreen" :weight bold))
("CANCELLED"  . shadow)
))

Bueno, hasta aquí hemos llegado hoy. ¿Qué más me recomendáis cambiar? 🙂

Referencias

FAQ de org

Colors Available to Emacs

Customizing Emacs en Emacs Beginner’s How to

Lo que he aprendido: lista de tareas en org mode

¡Llegó el momento en el que el modo org y Ondiz se ven las caras! Después de una temporada usando Emacs me ha picado el gusanillo y aprovechando que tenía que tener controladas mis tareas del curro, me he puesto a investigar org. Hoy os hablaré de mis primeros pasos en él, que consisten básicamente en escribir una lista de tareas. ¡Empecemos!

El modo org

El modo org es un modo para tomar notas, escribir, planear proyectos, manejar listas de tareas, gestionar el tiempo, publicar documentos y muchas otras cosas que se nos ocurran. Lo creó el profesor de astronomía Carsten Dominik cuando intentaba organizar mejor sus notas. Su idea era sacar directamente las tareas a realizar de las notas tomadas, por ejemplo, en una reunión, para que las tareas y las notas en lugar de ser dos cosas independientes se retroalimentasen.

Su primer paso fue mejorar el modo outline añadiendo indentación para que fuera más sencillo de leer y facilitando el manejo de los elementos de las listas. A partir de ahí fue ganando funcionalidad hasta convertirse en la herramienta multiusos que es ahora.

Una curiosidad de este modo es que su mascota es un unicornio, en su web dan varias explicaciones mi favorita es esta:

Org-mode is meant to show you the way, and an animal with two horns can not do this very well, can it?

Veamos ahora cómo hacer una lista de tareas sencilla.

Una lista de tareas

Antes de ponernos con la lista en sí debemos saber un par de cosas del modo org:

  • Cada documento comienza con los datos (autor, fecha …) y las opciones queremos establecer (indentación, idioma …)
  • Org tiene un lenguaje de marcado propio (similar a Markdown) donde los títulos se indican con asteriscos

Una vez entendido esto, solo nos queda saber que cualquier título se convierte en tarea si empieza por TODO, por ejemplo, convertimos un encabezado de segundo nivel en una tarea así:

** TODO Aplicar cambios

Debajo de esta tarea podemos seguir escribiendo al igual que si fuera un título normal y corriente. Incluso es posible añadir encabezados de nivel tres o superior que sean a su vez tareas. Luego para aclararnos mejor podemos colapsar los encabezados uno a uno con TAB (todos ellos con Shift+Tab) o moverlos de sitio con M-flechas.

Una vez acabada la tarea, con C-c C-t cambiamos su estado a DONE y se pintará en verde y nos hará sentir muy satisfechos. Si queremos que aparezca la fecha en la que cerramos la tareas podemos hacer uso de las opciones de las que os hablaba antes y añadir lo siguiente al inicio del documento:

#+STARTUP: logdone

Así, cuando marquemos la tarea como hecha, org nos añadirá una línea con la fecha de conclusión. Si nos gusta, podemos cambiar este comportamiento para siempre directamente en el archivo de configuración con:

(setq org-log-done 'time)

Otro tema que me mola es poder dividir las tareas grandes en listas con casillas para marcar, que tienen la sintaxis típica que nos solemos encontrar por ahí y cuyas casillas podemos marcar y desmarcar con C-c C-c (check):

- [X] Tarea 1
- [ ] Tarea 2

Estas listas de casillas pueden anidarse y si añadimos [%] o [/] a la principal org nos mostrará cómo de avanzada va la tarea, o bien en porcentaje o en fracción.

Esta es la funcionalidad más básica y con la que he estado jugando estos días pero tenemos además montones de opciones. Os cuento unas pocas:

  • Añadir más estados para las tareas usando las variables del documento, rulará por ellos cuando hagamos C-c C-t:
#+TODO: TODO FEEDBACK VERIFY | DONE CANCELED
  • Añadir prioridades A, B (por defecto) o C a nuestras tareas:
*** TODO [#A] Escribir entrada en el blog
  • Enlazar webs y archivos de nuestro ordenador:
[[RUTA][descripción]]

[[file: RUTA][descripción]]
  • Incluir tablas que se adaptan al contenido y en las que se puede usar la calculadora

  • Añadir tareas a la agenda con C-c C-s (schedule), que luego podremos ver en una vista diaria o semanal

Como veis podemos complicar esto hasta el infinito o mantenernos en la superficie. De hecho, una parte de su filosofía consiste en que cada cual adapte org a su estilo, pero que sea siempre posible usar solo lo simple. Yo de momento me siento muy feliz habiendo sido capaz de crear listas de este estilo:

tareas

Por cierto, una cosa curiosa es que las combinaciones de teclas de org dependen del contexto, es decir, la misma combinación tiene diferente significado según dónde la usemos, reduciendo el número de combinaciones que tenemos que memorizar.

En fin, me gusta como está pensado este modo, se adapta a mi forma de trabajar, supongo que porque proviene del mundo académico. ¡Parece que nunca más voy a tener que usar otro programa que no sea Emacs!

Os dejo con una charla que dio su creador en Google:

Referencias

Página de Org mode

Recursos de GNU Emacs y org-mode de Quijote Libre

Some tips for learning Org Mode for Emacs de Sacha Chuan

Get Organized with Emacs Org-mode en Linux Journal

Org-mode basics VI: A simple TODO list en Pragmatic Emacs

Org Mode – Organize Your Life In Plain Text!

Introduction to Literate Programming

En que ando: octubre

¡Ya ha pasado otro mes! Veamos qué he estado haciendo durante estos locos 31 días. Empecemos pues con lo que he compartido con vosotros por aquí. Más que nada he estado configurando mi ordenador del currelo y de paso aprendiendo movidas locas como que Matlab puede integrarse con git. He estado además afinando mi documentación matlabera, que nunca está demás mejorar en este aspecto.

Por otra parte, sigo intentando entender a Emacs poco a poco. Este mes me he metido un poco más en las expresiones regulares y descubierto un modo que nos avisa de los problemas de sintaxis en nuestro código.

Este mes también ha habido sitio para protestar y para que más gente conozca la lucha de los estudiantes de la Universidad de Granada para que la aplicación oficial de la universidad sea libre. ¡Vivan los gatetes libres!

Por último, os cuento un poco de lo que hago en el mundo real. ¿Recordáis que os hablé de un proyecto para impulsar las vocaciones científicas en las niñas? ¡Pues conocí a las niñas! Tengo tres clases de sexto y están casi tan locas como yo. Me echaron la bronca porque no soy astronauta como quería ser de pequeña y les parecí demasiado joven para dar clase en la uni. Qué majas.

¡Ah! ¡Que no se me olvide! Sigo mejorando el curso de LaTeX cuando tengo tiempo y el proyecto loco que tengo con mi hermano sigue su curso. Ambas cosas van lentas pero seguras. Espero tener noticias pronto.

Lo que he aprendido: el modo flycheck de Emacs

¡Hola, hermanos! Con el rollo de automejorarme he estado jugando un poco con el modo Flycheck de Emacs, un cacharro que nos mira el código y nos avisa de errores, malas prácticas y demás. Descubrí que existía gracias al blog de Maxxcan (que es parte del Planet Emacs en español como yo 😀 ) y fue tipo ¡oh! eso debo probarlo y hasta ahora. Venga, os cuento.

Flycheck

Flycheck es un comprobador de sintaxis para Emacs creado para sustituir a Flymake, el que viene de fábrica. Su función es detectarnos problemas en el código como paréntesis sin equilibrar, espacios al final de línea o problemas de estilo. Solo nos hace sugerencias subjetivas pero nos ayuda a ser más conscientes de lo que escribimos.

Soporta muchos lenguajes, ya que depende de otros programas externos para hacer la verificación, él solo aporta una interfaz cómoda. Lo que no soporta es Windows, aunque yo lo he usado igualmente y me ha funcionado igual que en GNU/Linux. A mí me interesa por LaTeX, Markdown, Python y Haskell (sobre todo por los dos primeros) así que voy a poner de ejemplo el caso de LaTeX.

Verifiquemos nuestro LaTeX

Para que Flycheck pueda sacar faltas a nuestro LaTeX necesitamos lacheck, una herramienta para detectar problemas comunes en LaTeX. Podemos descargarlo desde el repositorio de TeXLive o de los repositorios de nuestra distro. Una vez instalado abrimos un documento de LaTeX y activamos el modo con M-x flycheck-mode. Veremos unas marquitas en las líneas que tienen problemillas y abajo en el minibuffer nos dirá qué es lo que pasa. También podemos ver todos errores juntos como se ve en la imagen:

flycheck

Si nos gusta mucho mucho el modo podemos activarlo para todos los casos añadiendo lo siguiente al archivo de configuración:

;; Activar flycheck
(add-hook 'after-init-hook #'global-flycheck-mode)

Es chachi porque es listo y él solo averigua que verificador tiene que usar y lo usa si está disponible. Qué majo.

¿Y el Markdown?

Pues para Markdown tenemos Markdown lint que funciona exactamente igual pero que hay que instalar con gem:

[sudo] gem install mdl

Ahora cuando abramos un Markdown nos avisará de nuestras chapucillas. ¡Y hasta aquí hemos llegado! Me contáis a ver qué tal.

Referencias

Flycheck

Markdown lint

Manpage de Lacheck

Lo que he aprendido: expresiones regulares en Emacs

Hablé hace tiempo de las expresiones regulares por aquí (de hecho fue lo que inauguró la sección Lo que he aprendido) pero todavía no me había puesto a usarlas en serio en Emacs para buscar y reemplazar cosas. Algún día tiene que ser el día, así que voy a ver si puedo resumir aquí para futura referencia la sintaxis de las expresiones regulares de Emacs, cómo se usan para buscar y qué ventajas nos ofrecen a la hora de reemplazar texto.

Sintaxis

La sintaxis de las expresiones regulares de Emacs tiene muchas cosas en común con las de otros programas y lenguajes de programación pero también tiene sus peculiaridades. Con C-h S regexp podemos ver toda la información sobre las regexp de Emacs, como soy muy maja os resumo aquí algunas cosas:

  • Los símbolos ., +, *, ? y [] funcionan de la manera típica:
    • . sustituye a cualquier carácter excepto al de nueva línea. Por ejemplo, a.b pillará cualquier secuencia de tres caracteres que empiece por a y acabe con b.
    • * localiza el carácter precedente cualquier número de veces, incluido cero. Por ejemplo, ca* captará caaaa pero también c.
    • + lo mismo que el anterior pero obligando a que el carácter precedente aparezca como mínimo una vez. Al contrario que ca*, ca+ no captará c. Para no confundirlo con el anterior a este le llamo el uno o más.
    • ? similar a * pero solo capta el carácter precedente una vez o cero. Siguiendo con el ejemplo, ca? captará c y ca? pero no caaa. Yo a este le llamo el si hay sí.
    • [] indica opciones. Por ejemplo, [ac]a encontrará las cadenas aa y ca. Su contrario es [^] que elimina las opciones entre corchetes, de este modo, [^ac]a encontrará ba pero no ca.
  • En Emacs hay clases sintácticas que empiezan por \s y su negación por \S. Por ejemplo, \sw indica un carácter de palabra (letras en minúscula o mayúscula y dígitos) y \s. un carácter de puntuación. A diferencia de otros programas, Emacs no interpreta \s como un espacio, para eso está \s-.
  • También tenemos clases sintácticas que se usan entre corchetes (adicionales a los que ya llevan) como [:digit:] para los números y [:alnum:] para los caracteres alfanuméricos. Una cosa a tener en cuenta es que estas clases varían según el modo.

  • Hay marcadores de borde, por ejemplo, \b indica el borde de palabra, y ^ y $ el inicio y el fin de línea respectivamente.

  • Podemos capturar grupos con \(CAPTURA\) para después hacer referencia a ellos con \N, donde N es un número que indica su posición. Por ejemplo, si hacemos \([[:digit:]]+\) capturaremos en la variable \1 una tira de números seguidos.

Seguir leyendo →