Palaiseau, le mardi 30 juin 2026
Cher Journal,
En écrivant au sujet d'un possible projet concurrent à mon carnet, j'ai réalisé que cela fera bientôt un an que je n'ai pas fait la publicité des petites évolutions que j'ai pu apporter dans mon logiciel, au moins depuis la sortie de la version 1.6 en aout dernier. J'eus craint d'être saoulant avec mes histoires de logiciel pour organiser mes idées, mais il semble que je suis en réalité resté assez laconique sur le sujet. Il est probablement temps que je me rattrape.
J'avais déjà parlé des nouveautés de la version 1.6 en août dernier. Cette branche de versions a connu depuis de multiples corrections de problèmes mineurs. On y notera pêle-mêle des changements comme les suivants :
Cette version ajoute l'option -lm, ou --list-modules, qui permet de lister les modules installés dans le répertoire d'un carnet. Pour rappels, les modules sont des exécutables qui peuvent être invoqués avec l'option -m, ou --module, de carnet, pour faire des choses dans ledit carnet. Ces scripts peuvent par exemple faciliter les recherches avec des motifs spécifiques, ou faciliter l'implémentation de statistiques personnalisées. Pour les publications, comme pour l'instant je ne publie pas le dépôt git, j'ai à la place implémenté un moyen de déployer les archives tarball contenant des métadonnées comme le fichier CHANGES dans un format intermédiaire pour publication. De cette manière, j'ai également retiré le besoin d'invoquer la commande help2man pour produire le manuel : il fait partie de la publication, il n'y a plus qu'à le compresser avec gzip et à le déployer dans $PREFIX/share/man/man1 pour l'installer.
Je réfléchis encore à la manière de publier le dépôt git via mon site web, en sachant que j'ai déjà abandonné l'idée de permettre un git clone, au prétexte que cela nécessite un serveur web spécialisé ou l'activation de modules apache2 compliqués que je n'ai pas l'envie de déployer. Je pense que c'est une situation dans laquelle je paie le coût de vouloir faire des choses trop simples.
J'ai rajouté un moyen d'afficher et d'éditer un message du jour, avec les options --motd et --edit-motd respectivement. Le Message Of The Day apparait à chaque invocation du carnet. C'est utile pour lui donner une sorte de personnalité, ou des rappels qu'on ne veut oublier sous aucun prétexte, ou juste lui faire une couverture sympathique en art Ascii :
$ carnet # Dans exemple, l'éditeur `ed` illustre la saisie d'une entrée. 41501 i Je travaille à illustrer le fonctionnement de la couverture d'un carnet stylisée en utilisant de l'art ascii. J'ai à dessein ajusté le motd pour avoir quelque chose de très visuel, mais d'autres usages sont possibles, comme par exemple avoir à portée de main les références vers ses feuillets favoris. . w 41825 q ━┏┓━┏┓━┏┓━┏┓┏━━━━━━━━━━━━━━━━┏┓━┏┓━┏┓━┏┓┌┐ ┃┣┛┃┣┛┃┣┛┃┣┛┃ C A R N E T ┃┣┛┃┣┛┃┣┛┃┣┛││┌─ ─ ┛┛━┛┛━┛┛━┛┛━━━━━━━━━━━━━━━━━┛┛━┛┛━┛┛━┛┛━┙└┘ feuillet 2026-06-30T22:00 recorded in /home/emollier/doc/carnet/2026-27.txt.
Les dernières versions de la série 1.8 implémentent par ailleurs le support de mpc, le Media Player Client, comme alternative à mocp, le Music On Console Player.
Le seul changement de la version 1.9.0 est que la fonction de recherche --search se comporte désormais comme une vraie fonction de recherche, telle qu'on peut la trouver dans n'importe quelle application. Au lieu de bricoler avec des expressions rationnelles pour concaténer les motifs à rechercher dans les différents feuillets, le moteur de recherche implémenté en awk traite désormais chaque motif indépendamment pour afficher uniquement les feuillets qui contienne tous les motifs passés en argument, peu importe leur ordre d'apparition dans la ligne de commande. Ce changement s'est avéré essentiel pour améliorer l'ergonomie des recherches dans le carnet de manière substantielle. Elle se fait désormais de manière beaucoup plus intuitive. Les commandes suivantes sont désormais strictement équivalentes :
$ carnet -s mot1 mot2 mot3 $ carnet -s mot3 mot2 mot1
Auparavant, l'ordre des mots était important. À noter, passer ces mots comme un seul argument est toujours considéré comme un seul motif correspondant strictement à la chaine de caractères « mot1 mot2 mot3 ». « mot3 mot2 mot1 » est toujours une recherche différente. Ces deux commandes ne sont toujours pas équivalentes, et elles n'auront pas vocation à le devenir :
$ carnet -s 'mot1 mot2 mot3' $ carnet -s 'mot3 mot2 mot1'
Dans la série 1.10, j'ai modifié les options --feuillet et --edit-feuillet. Elles prennent désormais aussi bien des références au format YYYY-MM-DDThh:mm, comme toujours, que des dates pour afficher des journées complètes au format YYYY-MM-DD. Par exemple la commande :
$ carnet -f 2026-06-29
affichera l'ensemble des feuillets que j'ai saisi pendant la journée du 29 juin 2026. J'ai poussé jusqu'à ajuster --feuillet pour accepter les semaines au format YYYY-WW, ce qui est pratique quand la semaine constitue une unité de travail avec une certaine cohérence dans le monde de l'entreprise. La commande suivant ouvrira en édition le fichier correspondant à la semaine 27 de 2026 :
$ carnet -ef 2026-27
Je n'ai pas eu à retoucher à carnet depuis mi-mai et la sortie de la version 1.10.0, ce qui suggère que l'outil est désormais assez stable pour mes cas d'usage.
Je pense que je pourrais étendre la logique de sélection des feuillets à une année entière, mais il faut que je décide de la façon dont je veux me risquer à gérer la transition autour du jour de l'an. Est-ce que je veux tolérer de la marge de quelque jours afin d'afficher ce qu'il se passe pendant la semaine avant le nouvel an, ou après ? Le problème est qu'un jour comme le 31 décembre 2025 se trouve faire partie de la semaine 1 de 2026, donc utiliser un joker sur 2025-*.txt va sortir les dernier jours de l'année du résultat de recherche. Je ne pense pas que ce soit insurmontable, mais ça demandera de réfléchir un petit peu pour implémenter quelque chose d'efficace. Il faut par ailleurs que je garde en tête que je ne peux pas vraiment étendre cette logique à l'édition du texte de l'année entière, à moins que je considère par défaut d'ouvrir l'éditeur au premier de l'an, ce qui simplifierait grandement les choses.
Pour carnet 2, j'aimerais adopter un format de fichier un peu plus rationnel. L'idée serait qu'il puisse me servir à la fois de représentation pour le stockage du carnet, ainsi que de représentation intermédiaire pour faciliter le chaînage des recherches avec tout un tas de différents critères, parfois pas forcément adaptés aux expressions rationnelles, comme filtrer des informations dans période de dates. Je pense avoir vu quelque chose d'intéressant dans le projet concurrent jrnl. J'en reparlerais peut-être plus en détail un peu plus tard.
| Name | Last modified | Size | |
|---|---|---|---|
| Parent Directory | - |