Le HEREDOC est une structure de bash (mais pas que) très pratique pour passer de multiples lignes d’un seul coup à une commande, ou une fonction. Exemple : cat << __EOF__ De multiples lignes __EOF__ Le mot-clef __EOF__ est un délimiteur qui est libre. N’importe quelle chaine de caractères ascii est utilisable. Cette structure assez classique cache quelques subtilités que j’ai découvertes récemment. L’occasion parfaite de rédiger ce petit mémo. Rediriger vers un fichier Les opérateurs de redirection classiques (> et >>), sont utilisables, et doivent être placés après le délimiteur. cat << __EOF__ > /etc/ma/super.conf Clef=valeur Foo=bar __EOF__ Passer à une autre commande On peut également utiliser le pipe | après le délimiteur pour faire traiter la chaine par une autre commande. cat << __EOF__ | sed 's/bar/baz' Clef=valeur Foo=bar __EOF__ Fin du fin, on peut aussi rediriger le résultat dans un fichier. En fait la ligne après le délimiteur est à voir comme une ligne de commande classique. cat << __EOF__ | sed 's/bar/baz/' > /etc/ma/super.conf Clef=valeur Foo=bar __EOF__ Avec des variables De base, les substitutions sont actives dans le contenu du HEREDOC : cat << __EOF__ > /etc/ma/super.conf Hostname=$HOSTNAME Foo=bar __EOF__ Mais il peut arriver que l’on ne veuille pas les substituer dans le fichier final, pour conserver le symbole $. Oui, je pense à toi là, systemd … Et pour faire ça … Sans variables Il suffit d’entourer de guillemets le premier délimiteur : cat << '__EOF__' > /etc/ma/super.conf Hostname=$HOSTNAME Foo=bar __EOF__ Cela fonctionne également avec des guillemets doubles. Une autre méthode, un peu plus pénible cela dit, consiste à échapper le $ pour empêcher sa substitution. Il ne faut alors plus mettre de guillemets autour du délimiteur : cat << __EOF__ > /etc/ma/super.conf Hostname=$HOSTNAME Foo=bar __EOF__

J’ai remarqué un truc intéressant sur le fonctionnement de Zabbix lorsque l’on veut superviser des équipements via SNMP : il arrive que tous les items SNMP d’un host passent en erreur, avec pour seul retour, un message d’erreur d’authentification. Même si la configuration semble correcte (sauf sur un). Ce problème a déjà été rencontré et confirmé par un collègue. Le contexte J’étais en train de créer un nouveau template pour superviser un équipement en SNMPv3. Je l’ai appliqué à un host. Dans la liste, il y a un item qui était mal configuré au niveau du « Security Name ». À partir de là, même les items correctement configurés se sont mis en erreur. Précisons que cela peut se produire également en cas de mauvaise configuration de n’importe quel autre élément : protocole d’authentification, de chiffrement, etc. Ceci a été expérimenté avec les versions 4.0.x et 5.0.x. J’essaierai de mettre à jour si je constate la même chose sur des versions plus récentes. L’origine du problème Les processus de Zabbix gérant la communication en SNMP avec les équipements mettent en cache les données d’authentification pour un host donné. À partir de là, il suffit que le processus utilise les données d’un item mal configuré pour que l’erreur se propage à tous les items SNMP de ce host. Une correction à chaud sur l’interface web n’y changera rien. À noter que le problème inverse peut également se produire : Zabbix peut réussir à remonter les données d’un item mal configuré si le processus a d’abord pioché dans un qui l’est correctement. La solution Ici, il n’y en a qu’une : il faut stopper le service Zabbix, puis le relancer. Ainsi, les processus qui vont s’occuper du SNMP seront tués puis relancés, ce qui videra leur cache, et les forcera à prendre les bons identifiants.

En 2020, j’ai ajouté un blogroll en bas des articles. Je ne partageais que 3 liens (tirés au hasard) alors que j’ai bien plus que ça dans mes flux RSS. Après 3 ans et avoir remarqué le truc lors de la mise à jour de mon blog, j’ai commencé à trouver ça un peu triste de limiter à si peu, surtout que c’étaient souvent les mêmes qui étaient tirés au sort. Après avoir vu Lord supprimer le sien, j’ai commencé à me demander si je ne ferais pas la même chose. En plus, Openring est largement capable de récupérer plus que 3 articles. Ni une, ni deux, et après de nombreux jours de flemme, voici une nouvelle page toute fraîche pour accueillir l’idée : Ailleurs Pour cela, j’ai légèrement changé mon script de récupération : #!/usr/bin/env bash set -euo pipefail readonly BASEDIR=$(pwd) readonly OPENRING="${HOME}/MesDocs/Developpement/go/openring" selected_feeds="" feeds=( $(awk '/openring/ { print $1 }' "${HOME}/.newsboat/urls") ) nfeeds=${#feeds[@]} for (( index=0; index<${nfeeds} ; index++)) do selected_feeds="-s ${feeds[$index]} $selected_feeds" done echo $selected_feeds ${OPENRING}/openring -n ${nfeeds} $selected_feeds < ${OPENRING}/in-webring.html > ${BASEDIR}/layouts/partials/webring.html Comme avant, le fichier layouts/partials/webring.html est dans mon gitignore. Le template in-webring.html de openring ressemble à ça, à date d’écriture de cet article : {{ range .Articles }}

{{ .Title }}

Via {{.SourceTitle}} le {{.Date.Format "2006-01-02"}}

{{.Summary}}

{{ end }} Oui, il est beaucoup plus simple car se base sur les templates d’articles du blog. Ensuite, une nouvelle section vide pour générer la page dans le dossier layouts avec un appel à {{ partial "webring.html" . }}, puis un nouveau lien en en-tête du site, et le tour est joué. Ah oui, j’ai tout de même viré les règles CSS qui ne servent plus. Magie, pas besoin d’en rajouter vu cette structure de page ! Voici donc maintenant à disposition bien plus de liens vers d’autres sites et blogs. Ceci est encore mieux dans la démarche de partager plus de contenu indépendant. En guise de conclusion, je vais m’auto-citer, en utilisant le premier paragraphe de l’ancien post : Après tout, le but des blogs c’est le partage, alors renvoyer vers d’autres adresses ça fait partie du truc. Surtout si, de proche en proche, ça vous fait découvrir d’autres blogs qui vous intéressent. Et les blogs indépendants, c’est toujours cool.

La prise de notes sur ordinateur est un exercice tout à fait personnel qui peut être rapidement complexe. Cela va d’un simple fichier texte à un gros carnet virtuel, voire un wiki local, habituellement géré par un logiciel spécialisé. Ces logiciels sont très nombreux, et pour n’en citer que quelques-uns : Zim Joplin Zettlr Obsidian Votre éditeur de texte favori (avec ou sans plugins) OneNote Au niveau professionnel, j’ai tout utilisé tour à tour, et je dois dire que j’ai maintenant un faible pour Zettlr, après avoir passé de nombreuses années avec Zim. Je suis cependant actuellement sur Joplin. Zettlr refusant de fonctionner sur le PC pro sans que je trouve pourquoi. Mais chez moi, mes besoins sont bien plus légers. Utiliser de telles solutions ne me convient donc pas. J’ai beaucoup utilisé un simple fichier unique, édité avec Vim et lancé par un alias Bash, mais il faut avouer que ça a fini par m’embêter. Avec le temps j’ai accumulé beaucoup de notes et j’ai fini par ne plus m’y retrouver. À la recherche d’une solution Étant un grand utilisateur de Vim, je me suis d’abord penché sur quelques solutions à base de plugins : OrgMode VimWiki Vimboy Vim-notes Cependant j’ai rapidement abandonné. Au-delà de ne pas avoir envie d’alourdir mon éditeur avec des plugins, j’ai surtout eu la flemme d’apprendre de nouvelles commandes et une autre manière d’utiliser Vim. Il me fallait quelque chose de plus simple. La solution qui me convient Comme Vim sait gérer nativement le Mardown et le colore, je me suis naturellemnt dirigé vers ce format pour mes notes. Au niveau de l’organisation, j’ai un fichier index.md, placé dans un dossier dédié que j’ouvre avec mon alias : alias notes="$EDITOR ~/MesDocs/Textes/_notes/index.md" Dedans, j’ai simplement réorganisé mon gros fichier en petites sections, et dès qu’un sujet précis demande plus de deux lignes, je fais un fichier séparé avec un lien dans l’index. Pour ouvrir ce fichier (qu’il soit nouveau ou déjà existant), je me suis inspiré de la commande gf : je me place sur le nom du fichier à ouvrir et j’utilise cette nouvelle commande que j’ai ajouté à mon .vimrc : noremap gf :tabnew Et voilà ! J’ai une utilisation qui me convient, pour un effort minimal. Le tout sans dénaturer l’outil que j’utilise le plus au quotidien. Ce ne sera peut-être pas la solution idéale pour vous, mais si ma manière de faire vous aide à en trouver une qui vous inspire, tant mieux. Sinon, n’hésitez pas à consulter les quelques liens en bas de cet article. Liens Les plugins Vim envisagés : OrgMode VimWiki Vimboy Vim-notes Les logiciels de prise de notes : Zim Joplin Zettlr Obsidian Des pistes qui m’ont aidé (en anglais) : Konstantin du dev.to : « Taking notes in vim revisited » Le blog de Blinry : « Keeping a personal wiki » Aide de Vim : la commande gf

Pouvoir commenter des articles sur un blog afin d’interagir avec la personne qui rédige, c’est un concept presque aussi vieux que les blogs eux-mêmes. Les moyens pour le faire sont nombreux. Je pense que je ne vous apprends rien. Par contre, quand on parle de commentaires directement intégrés à la page d’un article, au lieu de s’échanger des mails qui seront publiés après-coup (avec autorisation), on tombe vite sur une situation compliquée lorsqu’il s’agit d’un site statique. En effet à ce moment-là les options deviennent vite limitées, et si l’on veut respecter les données des visiteurs, on en revient vite au bon vieux mail uniquement. Même s’il existe des solutions comme Isso. Ayant la flemme d’installer et d’administrer une instance Isso, et refusant de stocker le contenu ailleurs (coucou Disqus et autres), je me suis longtemps dit que j’allais laisser tomber et juste ouvrir ma boite mail de temps en temps. Puis un beau jour, je suis tombé par hasard sur un article de blog de Carl Schwan intitulé « Adding comments to your static blog with Mastodon ». Ajouter des commentaires à votre blog statique via Mastodon. Tous les mots-clefs intéressants pour moi sont là. En plus je dispose de ma propre instance sur le Fédiverse. Et si je testais ça ? Techniquement, comment ça fonctionne ? Lorsque l’on publie un pouet, ce dernier possède un identifiant unique sur l’instance. Lorsque des réponses y sont faites, ces pouets référence celui d’origine. L’API de Mastodon, et les autres implémentations (notamment Pleroma) permettent de récupérer ce pouet ainsi que toutes ses réponses. À condition que ces publications soient publiques. Il suffit donc de faire un petit appel API sur ce pouet, et de boucler sur les réponses. Le fameux point d’API est : https:///{{ host }}/api/v1/statuses/{{ id }}/context Avec cet appel, si notre pouet a des réponses, on récupère un json avec plein d’infos intéressantes. Notamment avec la clef descendants qui contient un tableau des pouets en réponse. De là, il suffit de boucler et d’extraire les champs qui nous intéressent. Mon implémentation Je me suis basé sur celle de Carl Schwan : j’ai fait un Partial dans mon thème Hugo et hop. commentaires.html {{ with .Params.comments.show }} {{ end }} Rien de bien compliqué. Dans un bloc séparé, si j’ai bien rempli l’en-tête de l’article, j’affiche le bouton pour charger les réponses à la demande ainsi qu’un petit texte explicatif. Je n’ai pas voulu faire un bouton avec une pop-up pour copier le lien du pouet et mettre les explications. Ensuite, le JS qui sse charge de récupérer le pouet et ses réponses, puis de boucler dessus pour générer le html qui sera ensuite inséré à la place du bouton. Un poil de CSS également pour la forme et … C’est terminé ! Les règles CSS à rajouter .fedi-comment { margin-bottom: 3rem; display: flex; gap: 1rem; flex-direction: column; flex-grow: 2; } #commentaires-fediverse { font-size: 0.8em; } .fedi-wrapper { display: flex; gap: 3rem; flex-direction: row; flex-direction: row; } .fedi-comment .comment { display: flex; flex-direction: row; gap: 1rem; flex-wrap: wrap; } .fedi-comment .comment-avatar img { width: 2rem; } .fedi-comment .content { flex-grow: 2; } .fedi-comment .comment-author { display: flex; flex-direction: column; } .fedi-comment .comment-author-name { font-weight: bold; } .fedi-comment .comment-author-name a { display: flex; align-items: center; } .fedi-comment .comment-author-date { margin-left: auto; } .fedi-comment-content p:first-child { margin-top: 0; } .comment-level { max-width: 1.5rem; min-width: 1.5rem; } .reply-original { display:none } #fediverseURL { background-color:var(--inner-blocks-bg-color); border: none; color:var(--inner-blocks-font-color); } Enfin presque, il manque un petit paramétrage en en-tête de l’article : [comments] show = true host = "mon.instance.pleroma" id = "id_du_pouet_principal" Tant que j’y suis, je pré-paramètre ça dans l’archétype également (à false, oui, le temps d’écrire tranquillement) : [comments] show = false host = "mon.instance.pleroma" id = "a_changer" Et maintenant ? Maintenant ? Il n’y a plus qu’à continuer de publier. Vu mon rythme, je ne pense pas voir la différence, mais je me dis que cela peut être plus sympa si jamais quelqu’un ayant déjà un compte sur une instance veut échanger avec moi, sans avoir à ouvrir son client mail. Le vrai soucis avec cette méthode, c’est que ça m’ajoute quelques opérations manuelles : Publier l’article en premier lieu (bon ça, je le faisais déjà avant). Faire un pouet (avec un lien vers l’article). Relever l’identifiant de ce pouet. Modifier l’en-tête de mon article pour y intégrer cet identifiant, afin d’activer les commentaires. Publier de nouveau l’article. Je finirais bien par réfléchir à une autre solution un jour, après tout je ne publie pas si souvent que cela. Et je suis content de proposer facilement un autre moyen d’échanger sur ce que j’écris. Qui sait, peut-être que j’aurais un jour plus de retours, ce qui me permettra de m’améliorer. C’est toujours ça. Par contre, ça va également me forcer à faire des pouets pour présenter mes nouveaux articles. Moi qui laissais le flux RSS faire son travail de l’ombre, ça me fait bizarre de me dire que je vais de moi-même pousser publiquement l’apparition d’un nouveau contenu. D’autres le font déjà très bien, certes, mais pour moi c’est quelque chose de tout nouveau. Dernier inconvénient : pour les anciens articles, il faudrait démarrer un fil sur le fédiverse, et, vous savez maintenant : récupérer les id de ces fils, et les paramétrer, pousser la mise à jour sur le blog, etc. Les liens L’article de Carl Schwan qui m’a décidé à faire ça (en anglais) Un article de Veronica Berglyd Olsen sur la manière de présenter les pouets récupérés (en anglais) Isso Un vieux post de Lord sur la mise en place de Isso

Sans utiliser les commandes classiques (ip, le NetworkManager, etc.), il reste possible d’avoir l’état de ses cartes réseau. Utile notamment en shell de secours ou autres environnements limités. Voire script. cat /proc/net/dev Très visuel quoiqu’un peu indigeste, on aura là les statistiques de toutes les cartes d’un coup. Difficile pour le scripting. Exemple : cat /proc/net/dev Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed lo:3612535985016 1504871864 0 0 0 0 0 0 3612535985016 1504871864 0 0 0 0 0 0 eth0:7018766441878 6754565612 0 4507 0 577 0 258427669 7457131069430 7742050090 0 1 0 0 0 0 eth1:45188287103 531585456 0 0 0 0 0 259548075 0 0 0 0 0 0 0 0 eth2: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth3: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 bond0:7063954728981 7286151068 0 4507 0 577 0 517975744 7457131069430 7742050090 0 1 0 0 0 0 Si on veut extraire les statistiques plus facilement via script, il vaut mieux se tourner vers les fichiers présents dans /sys/class/net/*/statistics/. cat /sys/class/net/INTERFACE/carrier et cat /sys/class/net/INTERFACE/operstate Peu pratique à la main si l’on a beaucoup d’interfaces, mais très pratique pour le scripting, ces fichiers permettent d’avoir l’état du branchement de la carte. Exemples (avec commandes bonus) : $ grep "" /sys/class/net/*/carrier /sys/class/net/bond0/carrier:1 /sys/class/net/eth0/carrier:1 /sys/class/net/eth1/carrier:1 grep: /sys/class/net/eth2/carrier: Argument invalide grep: /sys/class/net/eth3/carrier: Argument invalide /sys/class/net/lo/carrier:1 # --- $ grep "" /sys/class/net/*/operstate /sys/class/net/bond0/operstate:up /sys/class/net/eth0/operstate:up /sys/class/net/eth1/operstate:up /sys/class/net/eth2/operstate:down /sys/class/net/eth3/operstate:down /sys/class/net/lo/operstate:unknown Et enfin, au cas où, pour trouver l’adresse IP (attention, le contenu peut être indigeste) : cat /proc/net/fib_trie L’adresse physique de la carte sera dans : /sys/class/net/INTERFACE/address.

Vim possède beaucoup de raccourcis clavier et permet même de créer les siens via les directives map et toutes ses variantes. Cependant, comment faire pour en avoir des courts, facile à retenir, sans pour autant empiéter sur d’éventuels déjà existant ? Une réponse proposée par Vim et que je n’ai découverte que très récemment est : la « leader key ». C’est une touche spécifique permettant de préfixer ses raccourcis personnalisés, afin d’avoir un risque de collision bien plus faible, voire nul. Pour cela, Vim propose une séquence à placer dans nos configurations de raccourcis : . Par défaut, elle est paramétrée sur . Ce n’est pas très pratique sur des claviers non-QWERTY. Paramétrons Dans notre .vimrc, il suffit d’affecter une valeur à la variable globale mapleader : " vim 9 ou plus let g:mapleader = "," " sinon let mapleader = "," Si vous préférez la barre d’espace : let g:mapleader = " " Maintenant, on peut faire nos raccourcis. En voici 3 que j’utilise : nnoremap g :GrammalecteCheck nnoremap G :GrammalecteClear nnoremap h :nohl Maintenant, je n’ai plus que 2 touches à presser pour utiliser ces commandes. Youpi ! Notez au passage l’utilisation de nnoremap pour que le raccourci ne soit activable qu’en mode normal. C’est pour éviter que la virgule ne soit interceptée pendant le mode insertion. Si vous utilisez une autre touche, rien ne vous empêche d’utiliser une autre variante pour avoir ce raccourci utilisable dans tous les modes. Aller plus loin Vous pouvez également paramétrer plusieurs touches différentes dans votre configuration. Que ce soit pour avoir plus de raccourcis, ou bien pour avoir des exécutions différentes sur la même touche (activation puis désactivation d’une fonctionnalité par exemple). Ceci est possible grâce à l’interprétation des raccourcis qui se fait à la lecture de sa déclaration. Ainsi, en paramétrant une leaderkey différente avant chaque utilisation de map, on peut faire, par exemple : let mapleader = "," nnoremap g :GrammalecteCheck let mapleader = "-" nnoremap g :GrammalecteClear Ici j’ai donc comme commandes : ,g pour lancer Grammalecte, et -g pour nettoyer le résultat. Et voilà ! Puisque ce mécanisme repose sur le mapping de touches, il est possible d’utiliser n’importe quelle commande interne à Vim, mais également vos fonctions personnalisées si vous en avez. Ainsi que, comme montré dans l’exemple précédent, des commandes de plugin. Pratique ! Attention toutefois au piège de vouloir (re)mapper tout et n’importe quoi. Plus d’informations :help mapleader Votre moteur de recherche favori avec les termes « vim leader key »1 Astuce de fainéant pour vous laisser choisir votre meilleure source sur le sujet, tellement il y en a (en anglais surtout). ↩︎

Cette histoire commence à avoir des titres aussi interchangeables que ceux des adaptations de Resident Evil par Paul W.S Anderson … Bref, j’ai donc activé la compression en brotli hier soir. Comme pour gzip, je pré-compresse avant de servir le contenu. J’ai donc commencé par ajouter une ligne qui va bien dans mon script de publication : find "${PUBLICDIR}" -type f -regex '.*.(htm|html|txt|csv|xml|svg|js|json|css)$' -exec brotli -f -k {} ; brotli était déjà sur mon système, installé en tant que dépendance de curl. Ensuite, après avoir (spoiler : mal) vérifié avec nginx -V que brotli était présent, j’ajoute simplement un brotli_static on; dans la configuration sur le serveur. J’envoie le tout, puis je redémarre nginx : rc-service nginx stop rc-service nginx start # COIN ! Allons bon, nginx refuse de redémarrer en prétextant une erreur de type directive inconnue sur brotli_static. Une rapide recherche donne le paquet supplémentaire à installer : apk add nginx-mod-http-brotli rc-service nginx start Et voilà ! Observations et réflexions Le gain de place des fichiers compressés en brotli est assez intéressant, voyez plutôt : Tailles de quelques fichiers, en Ko 8133 10-erreurs-balade-moto.txt 3330 10-erreurs-balade-moto.txt.br 3609 10-erreurs-balade-moto.txt.gz 1467 check-list-fest.txt 698 check-list-fest.txt.br 746 check-list-fest.txt.gz 338 favicon.svg 179 favicon.svg.br 251 favicon.svg.gz 7711 index.html 1635 index.html.br 1989 index.html.gz 216450 index.json 67035 index.json.br 77608 index.json.gz 84006 index.xml 15587 index.xml.br 17653 index.xml.gz 17665 sitemap.xml 2298 sitemap.xml.br 2654 sitemap.xml.gz Par contre, vu que je pré-compresse et propose maintenant 3 formats, ça prend forcément un peu plus de place sur le disque. Mais dans mon cas, c’est négligeable. Il y a un côté plus amusant qu’utile pour un petit site statique à proposer des fichiers déjà compressés plutôt que de le faire à la volée. Je remarque qu’à la compression sur mon PC, ça prend un peu plus de temps. Cela dit sur le temps de décompression, je n’ai pas remarqué ni calculé pour voir ce qui était le plus rapide. Il y a moult comparatifs sur internet. Utiliser la charge de ma machine à la publication plutôt que celle sur serveur est néanmoins une décision que je trouve pertinente. Même si le serveur mettra en cache la ressource compressée, c’est toujours ça d’économisé. Surtout sur des petites machines. Mettre à disposition gzip et brotli, je ne sais pas si ça vaut réellement le coup. Au moins, vu la majorité de navigateurs qui supportent ce format, je peux toujours me dire que j’aide (à mon échelle) à économiser de la bande passante, surtout pour les personnes sur mobile. Liens L’épisode 1 L’épisode 2

Suite à mon aventure où j’ai mit en place de quoi coloriser les templates Hugo, je me suis dit que j’allais pouvoir aller plus loin en retirant mon gestionnaire de plugins. Pourquoi Via Vim-Plug, un gestionnaire léger mais suffisant, je n’utilise que deux plugins : DelimitMate Grammalecte (et avant LanguageTool) Du coup je me suis demandé pourquoi je garderai un gestionnaire pour si peu, alors que depuis vim 8 on a de quoi installer et isoler correctement des plugins. Comment Vim-Plug dépose les dossiers des plugins dans .vim/plugged. Il suffit de déplacer ces répertoires dans .vim/pack//start/. Chez moi c’est : .vim/pack/common/start/ (je ne me suis pas foulé pour le nom). J’ai donc juste eu à faire : mv .vim/plugged/* .vim/pack/common/start/ Ensuite, il faut retirer le code de Plug : rm .vim/autoload/plug.vim et retirer l’appel dans son .vimrc. À titre d’exemple, je n’avais que ces lignes à retirer : """ plugin management call plug#begin('~/.vim/plugged') Plug 'vim-scripts/delimitMate.vim' Plug 'vim-scripts/LanguageTool' call plug#end() Facile, et rapide. Réflexions Même si c’est pratique et que je comprends totalement l’utilité des gestionnaires de plugins, je n’utilise finalement que trop peu de greffons pour que ça ait un intérêt chez moi. Je n’ai appelé le gestionnaire que 2 fois depuis son installation (en 2017 environ !), et je ne descends pas ma conf sur tant de machines différentes que ça. Du coup, vu que c’est limite du code mort qui traine chez moi, alléger mon éditeur me semble être une décision pertinente. D’autant qu’en identifiant plus clairement les quelques plugins sur mon dépôt dotfiles public, je pourrais récupérer plus facilement ces éléments, et le partage est potentiellement plus facile. Surtout pour copier la conf sur des serveurs pros. Il y a de nombreux cas où une connexion directe vers l’extérieur n’est pas possible. Par contre, si ça fonctionne très bien de votre côté et que vous l’utilisez intensivement, ne vous cassez pas la tête et conservez votre gestionnaire de plug-ins et vos habitudes. Ça n’aurait aucun intérêt de tout péter, juste pour dire que « les gestionnaires c’est d’la merde », alors que tout fonctionne bien. Point bonus pour garder votre configuration actuelle si vous avez un environnement spécifique qui vous empêche de passer aux dernières versions de vim. Liens (En anglais) un article de Shapeshed sur le même sujet Présentation de Vim-Plug sur NixCraft Page Github de Vim-Plug Page vim.org de DelimitMate Page github du plugin grammalecte pour vim Page vim.org de LanguageTool La doc Vim sur les packages

Les templates des pages Hugo mêlent du HTML avec une syntaxe qui vient du langage Go. Et à l’écriture sous vim, petite surprise : il n’y a que les balises HTML qui sont correctement colorées : La coloration syntaxique d'origine. Bien mais pas top : les balises HTML sont correctement colorées mais pas les bouts de templates Go.
Dans un template de page qui comprend peu d’éléments Go, cela reste lisible dans soucis. Mais dans certains cas, on va se retrouver avec un fichier assez complexe en instructions de templates sans une seule coloration. Et là, c’est tout de suite plus pénible. Voyons comment améliorer les choses. La solution simple et rapide Il suffit d’installer le plugin Go pour Vim dans sa globalité. Tout est expliqué correctement sur la page du projet, mais ce n’est pas cette solution qui m’intéresse. La solution « complexe » et lente Mais plus légère, et moins difficile qu’imaginé. Après quelques recherches infructueuses contenant pas mal de résultats avec au choix un conseil sur un meilleur éditeur, ou bien une suggestion d’installer le greffon cité précédemment, je finis par tomber sur un article de blog datant de l’été 2022. Bon, ça parle surtout de NeoVim, mais c’est récent, et très certainement adaptable. Cependant, avant de créer des dossiers à la racine du dossier ~/.vim et d’y déposer des fichiers, intéressons-nous à une nouveauté de la version 8 de vim : les paquets (ou « packages » en anglais). Apparté sur les packages selon vim 8 Depuis cette version, il y a du nouveau dans les chemins de vim : ~/.vim/pack//start//. Toute structure de sous-dossiers et vimscripts, à condition de respecter la hiérarchie de dossiers correcte, sera ajoutée aux éléments que vim va exécuter. Pratique, pour des extensions de capacité. Ici, c’est un peu vague, mais un peut contenir tous les plugins que l’on veut. Exemple : ~/.vim/pack/collection_base/start/plugin_un/ ~/.vim/pack/collection_base/start/plugin_deux/ ~/.vim/pack/collection_base/start/plugin_trois/ C’est plus proche d’une collection d’un certain nombre de plugins que l’on voudrait déployer sur plein de serveur (par exemple pour un parc informatique). Rien n’empêche d’avoir des plugins supplémentaires dans une seconde collection, optionnelle, que l’on ne déploierait que sur certaines machines. Exemple (en reprenant le précédent) : ~/.vim/pack/collection_base/start/plugin_un/ ~/.vim/pack/collection_base/start/plugin_deux/ ~/.vim/pack/collection_base/start/plugin_trois/ ~/.vim/pack/collection_optionnelle/start/plugin_supp_un/ ~/.vim/pack/collection_optionnelle/start/plugin_supp_deux/ Je vous renvoie à la documentation si vous voulez plus de détails. Retour à notre problème Étape 1 : on ouvre son terminal préféré. Ensuite, direction le répertoire vim personnel : cd ~/.vim. S’il n’existe pas, on se rajoute le sous-dossier des packages, ainsi qu’un premier niveau : mkdir -p pack/common/start. Sautez cette étape si vous avez déjà un dossier de paquets. Tant qu’à faire, entrons-y : cd pack/common/start. Remplacez par le vôtre si vous avez déjà un dossier de paquets. Créons un espace dédié pour cette extension : mkdir gohtmltmpl et allons-y : cd gohtmltmpl. Créons les répertoires suivants : mkdir ftplugin/ mkdir indent/ mkdir syntax/ Maintenant, il faut récupérer depuis le projet du plugin Go les fichiers gohtmltmpl.vim qui correspondent. Attention, il y a une subtilité : dans le dossier syntax il faut également récupérer et déposer gotexttmpl.vim. Pour terminer, il faut créer un dossier ftdetect et y placer le code suivant dans un fichier gohtmltmpl.vim : " Source : https://tech.serhatteker.com/post/2022-06/nvim-syntax-highlight-hugo-html/ function DetectGoHtmlTmpl() if expand('%:e') == "html" && search("{{") != 0 setfiletype gohtmltmpl endif endfunction augroup filetypedetect " gohtmltmpl au BufRead,BufNewFile *.html call DetectGoHtmlTmpl() augroup END C’est terminé. Nous avons donc : .vim/pack/common/start/gohtmltmpl/ ├── ftdetect │   └── gohtmltmpl.vim ├── ftplugin │   └── gohtmltmpl.vim ├── indent │   └── gohtmltmpl.vim └── syntax ├── gohtmltmpl.vim └── gotexttmpl.vim Le résultat Un redémarrage de vim plus tard, voici ce que cela donne : La coloration syntaxique améliorée. Les éléments du langage de template de Go sont maintenant reconnus et colorés.
C’est tout de même mieux ! Surtout sur les shortcodes et autres partials qui peuvent ne contenir quasi que des éléments de template Go, sans un seul bout de html. Voici un exemple : Exemple d'un 'partial' correctement colorisé ne contenant que des instructions de template Go.
Réflexion sur le sujet Évidemment, la solution que j’ai préférée mettre en place comporte quelques inconvénients. Dans un premier temps, plus d’opérations (manuelles) à effectuer pour la mise en place. Ensuite, je n’aurais pas les éventuelles mises à jour de syntaxe et corrections de bugs. Encore que, on peut tirer directement avec git et faire régulièrement ce qu’il faut. Cela dit, une fois que c’est fait, la solution est autonome. Pas besoin de brancher ça sur un gestionnaire de greffons, ni d’installer tout un outillage dédié à Go, alors que je voulais juste la coloration des templates pour Hugo. De plus je prends le pari que le moteur de templates ne va pas changer radicalement du jour au lendemain. À vous de peser le pour et le contre, mais je pense que dans un cadre où l’on ne développe pas en Go, il est inutile de tirer autant de ressources pour ensuite coloriser un seul type de fichiers. Et pour voir plus loin, en vrai, quand on rajoute des plugins stables, qu’on en fait un miroir sur un autre dépôt (le sien ou un dans un cadre pro), ou qu’on les partage avec plusieurs machines, cette organisation de dossiers est clairement plus propre, car elle isole réellement les éléments les uns des autres. Au prix de quelques sous-dossiers supplémentaires cela dit. Maintenant que j’ai découvert cette fonctionnalité et fait ça sans passer par Plug, je me demande si je ne vais pas complètement m’en passer. Affaire à suivre. Liens L’article sur le blog de Serhat Teker qui m’a bien aidé Le dépôt GitHub du plugin Go pour Vim L’article de Shapeshed qui m’a permis de comprendre les paquets sous vim 8 La doc de Vim sur les packages