La recherche dans l’historique regarde désormais dans vos documents
Rechercher dans votre historique ne comparait auparavant que les noms de fichiers. Une fois connecté, la recherche trouve désormais aussi un document d’après ce qui est écrit à l’intérieur — le champ du nom fonctionne exactement comme avant, il cesse simplement d’être la seule porte d’entrée.
Personne ne se souvient de la façon dont il a nommé un fichier. On se souvient d’une phrase qu’il contenait, du nom du client dont il était question, ou de la seule commande que contenait le runbook. Le champ en haut de votre historique ne pouvait auparavant rien faire de tout cela, car il ne comparait jamais que ce que vous tapiez aux noms de fichiers.
Deux recherches, un seul champ
Tapez dedans, et deux choses se produisent désormais à la fois. Le filtre par nom fonctionne là où il a toujours fonctionné — dans le navigateur, sur chaque ligne de la page, instantanément, pour les conversions enregistrées comme pour les autres. Et un instant plus tard, si vous êtes connecté, le serveur répond avec les documents enregistrés dont le texte correspond, classés selon la qualité de la correspondance, et ces lignes rejoignent celles que le nom avait déjà trouvées.
Vous n’avez pas à choisir entre les deux. Une requête moitié nom de fichier, moitié phrase dont vous vous souvenez trouve les deux types de lignes, et une requête qui ne correspond à rien par le contenu laisse simplement le filtre par nom tel qu’il était. La requête est différée pour éviter les envois à chaque frappe, et une recherche qui échoue laisse la liste fonctionner plutôt que de la remplacer par une erreur.
D’où vient l’index
Chaque document enregistré porte un tsvector de son Markdown, écrit au moment où le document est enregistré et indexé dans Postgres. La correspondance utilise websearch_to_tsquery, la syntaxe est donc celle que tout champ de recherche a appris aux gens : "une phrase entre guillemets" pour des mots dans cet ordre, or entre des alternatives, un - en tête pour exclure.
C’est une configuration délibérément simple — pas de racinisation, pas de liste de mots vides. Les mots correspondent tels qu’ils ont été tapés, ce qui veut dire que convert ne trouve pas converting, et qu’aucune de vos recherches n’est réinterprétée en silence. Chercher dans la source Markdown plutôt que dans la page rendue a un effet secondaire à connaître : l’adresse d’un lien, un bloc de code et un titre sont tous du texte que l’on peut retrouver.
Ce qu’elle n’atteint pas
Une conversion qui n’existe que dans ce navigateur n’a aucune ligne dans la base de données, rien n’est donc indexé pour elle, et elle continue à correspondre par le nom seul — la conséquence honnête du fait que les conversions restent locales jusqu’à ce que vous les enregistriez. Les documents que quelqu’un a partagés avec vous ne sont pas couverts non plus ; le filtre qui les liste se base sur le nom.
Depuis un script, c’est un seul paramètre : GET /api/v1/documents?q=…, ou tp list --q "…", qui renvoie les correspondances, les meilleures d’abord, la plus récente de deux égales avant la plus ancienne.
Autres lectures : convertir des fichiers Markdown par lots, et la documentation qui vit dans le dépôt.