Como ya te expliqué en este artículo, al retomar este blog quería mejorar la navegación y, para ello, decidí implementar un buscador que permitiera localizar contenido de la manera más eficaz posible. El tema con el que está generado el blog, Mainroad, incluye la posibilidad de renderizar un buscador en la barra lateral con un sencillo ajuste en el archivo de configuración de Hugo, config.toml.

[Params.sidebar]
  # Enable widgets in given order
  widgets = ["image", "search", "categories"]

La caja de búsqueda es sencilla, me gusta el estilo, pero cuando se visualiza el blog en una pantalla más pequeña la barra lateral que la contiene se muestra debajo de los primeros posts. Yo prefiero que el buscador esté siempre visible, desde el inicio, para que de este modo se pueda acceder al contenido rápidamente sin tener que navegar a la parte inferior del blog, así que probé a sacar la caja de búsqueda de la barra lateral y colocarla debajo del título, justo antes del primer artículo. Gracias a que el widget de búsqueda esta escrito en su propio partial, es sencillo probar la caja de búsqueda, en esa ubicación, añadiendo una única línea de código en la plantilla base del blog.

Hugo se presenta como el constructor de sitios web más rápido del mundo. Está escrito con Go y genera sitios de forma estática con la intención de ofrecer mejor rendimiento, seguridad y facilidad de uso. Por cada petición que recibe un sitio generado dinámicamente su servidor HTTP crea un nuevo archivo HTML. Con el tiempo estos generadores de sitios dinámicos comenzaron a almacenar algunas páginas en caché para mejorar el rendimiento. En tanto que Hugo no genera las páginas dinámicamente, sino que renderiza todos los archivos HTML en tu computadora, podemos definirlo como un generador de sitios estáticos. Es como si un generador de sitios dinámicos almacenara todas las páginas en caché. Este método te permite revisar todas las páginas en local tal cual serán enviadas al cliente y, además, el servidor HTTP las servirá usándo únicamente una fracción de cómputo y memoria de la que necesitaría un sitio generado dinámicamente.

Cuando gestionaba mis dotfiles era habitual encontrarme, entre los archivos modificados, al misterioso netrwhist. Antes que nada debes de saber que netrw es un script conectable a vim, que está orientado a redes y que permite lectura, escritura y navegación. netrwhist es el archivo donde netrw guarda un histórico de los directorios que fueron modificados. netrw tiene bastantes opciones de configuración:

let g:netrw_banner = 0
let g:netrw_liststyle = 3
let g:netrw_browse_split = 4
let g:netrw_altv = 1
let g:netrw_winsize = 25
let g:netrw_dirhistmax  = 10
let g:netrw_dirhist_cnt = 6

Un modo de no versionar este histórico es usar el parámetro de configuración netrw_home para guardar su histórico fuera del repositorio dotfiles.

Hace poco un compañero me preguntó cómo podía consultar los archivos que había gestionado en un desarrollo, desde la versión que había partido, hasta la versión actual en la que se encontraba. Consultando un poco dimos con esta opción,

$ git diff 0819dfcb 20620b5b --name-only

Y el resultado era exáctamente el que buscábamos, nombres de los archivos que habian sufrido algún tipo de modificación entre los dos commits que le estábamos pasando al comando git diff.