La búsqueda del historial ya mira dentro de sus documentos
Buscar en el historial antes solo comparaba con el nombre del archivo. Con la sesión iniciada, ahora también encuentra un documento por lo que está escrito dentro — el campo de nombre sigue funcionando exactamente igual que antes, solo deja de ser la única entrada.
Nadie recuerda cómo llamó a un archivo. Recuerda una frase que había en él, el nombre del cliente sobre el que trataba, o el único comando que contenía el runbook. El campo en la parte superior de tu historial antes no podía ayudar con nada de eso, porque solo comparaba lo que escribías con los nombres de archivo.
Dos búsquedas, un solo campo
Al escribir en él, ahora ocurren dos cosas a la vez. El filtro por nombre funciona donde siempre funcionó — en el navegador, sobre cada fila de la página, al instante, tanto en conversiones guardadas como sin guardar. Y un instante después, si tu sesión está iniciada, el servidor responde con los documentos guardados cuyo texto coincide, ordenados por lo bien que coinciden, y esas filas se suman a las que el nombre ya había encontrado.
No hay que elegir entre ambas. Una consulta que es mitad nombre de archivo y mitad frase recordada encuentra los dos tipos de fila, y una que no coincide con nada por contenido simplemente deja el filtro por nombre como estaba. La petición tiene un retardo antes de enviarse, así que escribir no genera una petición por cada tecla, y una búsqueda que falla deja la lista funcionando en lugar de sustituirla por un error.
De dónde viene el índice
Cada documento guardado lleva un tsvector de su Markdown, escrito en el momento en que el documento se guarda e indexado en Postgres. La coincidencia se calcula con websearch_to_tsquery, así que la sintaxis es la que cualquier campo de búsqueda ya ha enseñado a la gente: "una frase entre comillas" para palabras en ese orden, or entre alternativas, un - inicial para excluir.
Es una configuración deliberadamente sencilla — sin derivación de raíces y sin lista de palabras vacías. Las palabras coinciden tal como se escribieron: buscar convert no encuentra converting, y tampoco se reinterpreta en silencio nada de lo que buscas. Buscar en la fuente Markdown en lugar de en la página ya compuesta tiene un efecto secundario que conviene conocer: la dirección de un enlace, un bloque de código y un encabezado son también texto que se puede buscar.
Lo que no alcanza
Una conversión que solo existe en este navegador no tiene fila en la base de datos, así que no hay nada indexado para ella y sigue encontrándose solo por el nombre — la consecuencia honesta de que las conversiones permanezcan locales hasta que se guardan. Los documentos que alguien compartió contigo tampoco están cubiertos; el chip que los lista filtra por nombre.
Desde un script, lo mismo es un solo parámetro: GET /api/v1/documents?q=…, o tp list --q "…", que devuelve las coincidencias mejores primero, y entre dos iguales, la más reciente antes que la más antigua.
Relacionado: convertir archivos Markdown por lotes y documentación que vive en el repositorio.